Add server-side OCSP stapling to the BCJSSE provider and the low-level TLS API, answering status_request and status_request_v2 with a certificate_status message for TLSv1.2 and, from the same TlsServer.getCertificateStatus callback, a per-CertificateEntry extension for TLSv1.3, behind jdk.tls.server.enableStatusRequestExtension and a per-SSLContext response cache, dropping the echoes a resumed handshake would otherwise replay, reading the TLSv1.3 form on the client, dropping a response too large for its CertificateEntry to carry rather than failing the handshake over it, and clearing the status_request_v2 and trusted_ca_keys a reused TlsServer would otherwise carry into a following handshake, relates to github #1157.

Author: dghgit

CONTRIBUTORS.html

@@ -607,6 +607,7 @@
 <li>Arpan Sharma &lt;https://github.com/Arpan0995&gt; - initial audit of BCPQC provider consistency starting with HQC, which led to the exposure of a number of issues in the JCA provider service interfaces for other BCPQC algorithms.</li>
 <li>Flowdalic &lt;https://github.com/Flowdalic&gt; - initial implementation of an AnimalSniffer-based Android API-level compatibility check for the Gradle build (PR #336).</li>
 <li>hannesa2 &lt;https://github.com/hannesa2&gt; - initial Dependabot configuration for the Gradle and GitHub Actions ecosystems (PR #883).</li>
+<li>vladhuma &lt;https://github.com/vladhuma&gt; - initial implementation of server-side OCSP stapling for the BCJSSE provider, on behalf of Thales Group (PR #1740).</li>
 </ul>
 </body>
 </html>

core/src/main/java/org/bouncycastle/util/Properties.java

@@ -70,7 +70,8 @@ public class Properties
     public static final String X509_CRLDP_PROTOCOLS = "org.bouncycastle.x509.CRLDP_protocols";
 
     /**
-     * The largest OCSP response, in bytes, the CertPath validator will read from a responder.
+     * The largest OCSP response, in bytes, the CertPath validator - or the JSSE server's OCSP
+     * stapling fetch - will read from a responder.
      * A responder's Content-Length can narrow this but never widen it, so a responder declaring
      * (and sending) hundreds of megabytes is cut off rather than read into the heap. Default is
      * 64K, which is far above any real response; a value of zero or less is ignored and the

docs/releasenotes.html

@@ -86,7 +86,8 @@
  * refreshed out of band, an in-process responder as here) is entirely the application's
  * choice, which is the point of the callback.
  * <p>
- * Two things the callback has to get right, both illustrated below:
+ * Two things the callback has to get right up to (D)TLS 1.2, both illustrated below
+ * (TLS 1.3 reads the shape differently &mdash; see <b>Scope</b>):
  * <ul>
  * <li>Which <i>shape</i> of response to return. Ask
  * {@code context.getSecurityParametersHandshake().getStatusRequestVersion()}: 1 means the
@@ -101,12 +102,20 @@
  * wants to answer RFC 6961 clients must override it.</li>
  * </ul>
  * <p>
- * <b>Scope:</b> the "certificate_status" handshake message exists only up to (D)TLS 1.2.
- * TLS 1.3 carries the response in a per-CertificateEntry "status_request" extension
- * instead (<a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.1">RFC 8446 sec.
- * 4.4.2.1</a>) and {@code getCertificateStatus()} is not consulted there; this example
- * therefore negotiates TLS 1.2. Note also that this is the low-level TLS API &mdash; the
- * BCJSSE provider does not currently offer server-side stapling.
+ * <b>Scope:</b> this example negotiates TLS 1.2, where the response travels as one
+ * "certificate_status" handshake message covering the whole chain. That message does not
+ * exist in TLS 1.3, which instead carries each response in a "status_request" extension of
+ * the CertificateEntry holding the certificate it answers for
+ * (<a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.1">RFC 8446 sec.
+ * 4.4.2.1</a>). The callback is the same one either way &mdash; {@code TlsServerProtocol}
+ * distributes what it returns across those entries &mdash; so the only thing that changes
+ * for an implementation is how the shape is chosen: the status request version is always 1
+ * in TLS 1.3 ("status_request_v2" is left out of it by RFC 8446 sec. 4.2.1), so a server
+ * with responses for the intermediates as well returns the
+ * {@link CertificateStatusType#ocsp_multi} shape there regardless, answering positionally
+ * against the chain. Note also that this is the low-level TLS API; the BCJSSE provider
+ * fetches and staples responses of its own accord, behind the
+ * {@code jdk.tls.server.enableStatusRequestExtension} system property.
  */
 public class OCSPStaplingServerExample
 {

misc/src/main/java/org/bouncycastle/tls/examples/OCSPStaplingServerExample.java

@@ -38,6 +38,8 @@ final class ContextData
     private final SignatureSchemeInfo.PerContext signatureSchemes;
     private final int maxHandshakeMessageSize;
     private final int handshakeTimeoutMillis;
+    private final boolean serverEnableStatusRequest;
+    private final OcspStapleCache ocspStapleCache;
 
     ContextData(boolean fipsMode, JcaTlsCrypto crypto, BCX509ExtendedKeyManager x509KeyManager,
         BCX509ExtendedTrustManager x509TrustManager, Map<String, CipherSuiteInfo> supportedCipherSuites,
@@ -62,6 +64,15 @@ final class ContextData
             "jdk.tls.maxHandshakeMessageSize", 32768, 1024, Integer.MAX_VALUE);
         this.handshakeTimeoutMillis = PropertyUtils.getIntegerSystemProperty(
             "org.bouncycastle.jsse.handshakeTimeoutMillis", 0, 0, Integer.MAX_VALUE);
+        /*
+         * NOTE: read per context rather than once per class load, unlike the neighbouring jsse
+         * switches. SunJSSE reads this one per context too (an SSLContextImpl instance field), so a
+         * process can host one SSLContext that staples and another that does not.
+         */
+        this.serverEnableStatusRequest = PropertyUtils.getBooleanSystemProperty(
+            "jdk.tls.server.enableStatusRequestExtension", false);
+        // nothing reaches the cache unless a server in this context staples, so don't build one
+        this.ocspStapleCache = serverEnableStatusRequest ? OcspStapleCache.create(crypto.getHelper()) : null;
     }
 
     int[] getActiveCipherSuites(JcaTlsCrypto crypto, ProvSSLParameters sslParameters,
@@ -207,6 +218,29 @@ int getHandshakeTimeoutMillis()
         return handshakeTimeoutMillis;
     }
 
+    /**
+     * Whether a server in this context offers RFC 6066 status_request / RFC 6961 status_request_v2,
+     * from <code>jdk.tls.server.enableStatusRequestExtension</code>. Off unless asked for, since
+     * enabling it has the server make outbound OCSP requests on a client's behalf.
+     */
+    boolean isServerEnableStatusRequest()
+    {
+        return serverEnableStatusRequest;
+    }
+
+    /**
+     * The OCSP responses available for a server in this context to staple. Held per context, as the
+     * JDK holds its own StatusResponseManager, so that connections share it - a cache scoped to a
+     * connection would never see a second hit.
+     *
+     * @return the cache, or null when {@link #isServerEnableStatusRequest()} is false and nothing
+     *         would ever ask it for a response.
+     */
+    OcspStapleCache getOcspStapleCache()
+    {
+        return ocspStapleCache;
+    }
+
     NamedGroupInfo.PerConnection getNamedGroupsClient(ProvSSLParameters sslParameters,
         ProtocolVersion[] activeProtocolVersions)
     {

tls/src/main/java/org/bouncycastle/jsse/provider/ContextData.java

@@ -57,6 +57,7 @@
 import org.bouncycastle.tls.TlsContext;
 import org.bouncycastle.tls.TlsCredentialedDecryptor;
 import org.bouncycastle.tls.TlsCredentialedSigner;
+import org.bouncycastle.tls.TlsExtensionsUtils;
 import org.bouncycastle.tls.TlsUtils;
 import org.bouncycastle.tls.TrustedAuthority;
 import org.bouncycastle.tls.crypto.TlsCertificate;
@@ -471,10 +472,12 @@ static Certificate getCertificateMessage13(JcaTlsCrypto crypto, X509Certificate[
         {
             JcaTlsCertificate certificate = new JcaTlsCertificate(crypto, chain[i]);
 
-            // TODO[tls13] Support various extensions
-            Hashtable<Integer, byte[]> extensions = null;
-
-            certificateEntryList[i] = new CertificateEntry(certificate, extensions);
+            /*
+             * TODO[tls13] Support various extensions. The OCSP staples of RFC 8446 sec. 4.4.2.1 are
+             * attached by the protocol layer from getCertificateStatus() - see
+             * TlsUtils.add13CertificateStatus.
+             */
+            certificateEntryList[i] = new CertificateEntry(certificate, null);
         }
 
         return new Certificate(certificateRequestContext, certificateEntryList);
@@ -615,6 +618,76 @@ static List<byte[]> getStatusResponses(CertificateStatus certificateStatus) thro
         return null;
     }
 
+    /**
+     * The stapled responses from a TLS 1.3 Certificate message, where RFC 8446 sec. 4.4.2.1 carries
+     * each one in a "status_request" extension of the CertificateEntry it belongs to rather than in a
+     * CertificateStatus handshake message.
+     * <p/>
+     * The result is positional: element <code>i</code> answers for certificate <code>i</code> of the
+     * chain, with a zero-length element where an entry carried no staple. That is the contract
+     * {@link ProvX509TrustManager} relies on when it pairs the responses with the chain - appending
+     * only the staples that are present would attribute an intermediate's response to the
+     * end-entity.
+     *
+     * @return the responses, or null if no entry carried one.
+     */
+    static List<byte[]> getStatusResponses13(TlsContext context, Certificate certificateMessage)
+        throws IOException
+    {
+        /*
+         * RFC 8446 4.2: a server does not answer an extension the client did not send. An
+         * unsolicited staple is ignored rather than made a handshake failure, which is how this
+         * library has always treated one.
+         */
+        if (context.getSecurityParametersHandshake().getStatusRequestVersion() < 1)
+        {
+            return null;
+        }
+
+        CertificateEntry[] certificateEntryList = certificateMessage.getCertificateEntryList();
+        int count = certificateEntryList.length;
+
+        ArrayList<byte[]> statusResponses = new ArrayList<byte[]>(count);
+
+        boolean anyStatusResponse = false;
+        for (int i = 0; i < count; ++i)
+        {
+            byte[] statusResponse = getStatusResponse13(context, certificateEntryList[i]);
+
+            anyStatusResponse |= (statusResponse.length > 0);
+            statusResponses.add(statusResponse);
+        }
+
+        return anyStatusResponse ? Collections.unmodifiableList(statusResponses) : null;
+    }
+
+    private static byte[] getStatusResponse13(TlsContext context, CertificateEntry certificateEntry)
+        throws IOException
+    {
+        Hashtable<?, ?> extensions = certificateEntry.getExtensions();
+        if (null == extensions)
+        {
+            return TlsUtils.EMPTY_BYTES;
+        }
+
+        byte[] extensionData = (byte[])extensions.get(TlsExtensionsUtils.EXT_status_request);
+        if (null == extensionData)
+        {
+            return TlsUtils.EMPTY_BYTES;
+        }
+
+        /*
+         * RFC 8446 4.4.2.1: "the body of the "status_request" extension from the server MUST be a
+         * CertificateStatus structure as defined in [RFC6066]" - so a single response, never the
+         * ocsp_multi form. A malformed one is a decode_error, as it already is for the TLS 1.2
+         * CertificateStatus handshake message.
+         */
+        CertificateStatus certificateStatus = TlsExtensionsUtils.readStatusRequestExtension13(context,
+            extensionData);
+
+        return getStatusResponse(certificateStatus.getOCSPResponse());
+    }
+
     static X500Principal[] getTrustedIssuers(Vector<TrustedAuthority> trustedCAKeys) throws IOException
     {
         if (null == trustedCAKeys || trustedCAKeys.isEmpty())

tls/src/main/java/org/bouncycastle/jsse/provider/JsseUtils.java

@@ -0,0 +1,59 @@
+package org.bouncycastle.jsse.provider;
+
+import java.util.Date;
+
+import org.bouncycastle.asn1.ocsp.OCSPResponse;
+
+/**
+ * An OCSP response held for stapling, together with the validity interval the responder stated for
+ * the certificate it answers about.
+ * <p/>
+ * The response is carried verbatim as it arrived from the responder; it is <b>not</b> validated
+ * here. A stapling server is a relay - RFC 6066 sec. 8 has it pass the responder's answer through to
+ * the client, and the client is the party that verifies the responder's signature and decides what
+ * the answer means. The times are extracted only so that {@link OcspStapleCache} can tell how long
+ * the response may be reused, which is a caching question rather than a trust one.
+ */
+final class OcspStaple
+{
+    private final OCSPResponse response;
+    private final Date thisUpdate;
+    private final Date nextUpdate;
+
+    /**
+     * @param response   the response as received from the responder.
+     * @param thisUpdate the thisUpdate of the SingleResponse answering for the certificate.
+     * @param nextUpdate the nextUpdate of that SingleResponse, or null if it stated none.
+     */
+    OcspStaple(OCSPResponse response, Date thisUpdate, Date nextUpdate)
+    {
+        this.response = response;
+        this.thisUpdate = copy(thisUpdate);
+        this.nextUpdate = copy(nextUpdate);
+    }
+
+    OCSPResponse getResponse()
+    {
+        return response;
+    }
+
+    Date getThisUpdate()
+    {
+        return copy(thisUpdate);
+    }
+
+    /**
+     * @return the stated nextUpdate, or null if the responder stated none. RFC 6960 sec. 4.2.2.1
+     *         reads an absent nextUpdate as "newer revocation information is available all the
+     *         time", so a response without one is never reused from the cache.
+     */
+    Date getNextUpdate()
+    {
+        return copy(nextUpdate);
+    }
+
+    private static Date copy(Date date)
+    {
+        return null == date ? null : new Date(date.getTime());
+    }
+}