RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3

Xuelei Fan xuelei.fan at oracle.com
Sat Jan 4 17:27:57 UTC 2020

1239             // The consuming happens in server side only.
typo? server -> client

It wold be nice to add a debug log that this extension get ignored.  But 
may not need to define this consumer as it is not supported.

As this fix does not implement this feature yet, is it possible to just 
define it without the on-load consumer?

Otherwise, it looks fine to me.

BTW, this issue reminders me a common problem: if an extension is 
supported in a handshake message, we need to know all other handshake 
messages that could use the extension, and define an SSLExtension enum 
for them.  Otherwise, a similar issue could happen.  I think it would be 
challenge to know that in practice.

So I was just wondering, could we just release the check in the 
SSLExtensions.java implementation (from line 71 to 95)?  If the 
extension for the specific handshake type is not defined, just ignore 
it, except for ServerHello?  I think the behavior complies to the TLS 
1.3 protocol.

if (SSLExtension.isConsumable(extId) &&
     SSLExtension.valueOf(handshakeType, extId) == null) {
-   } else {
+   } else if (handshakeType == SSLHandshake.SERVER_HELLO) {
         throw hm.handshakeContext.conContext.fatal(
               "extension (" + extId +
               ") should not be presented in " + handshakeType.name);
+   } else {
+       isSupported = false;
+       // debug log to ignore unknown extension for handshakeType


On 1/3/2020 10:06 AM, Jamil Nimeh wrote:
> Hi All, the golang folks have been running into an issue where our JSSE 
> client treats the status_request extension in a CertificateRequest 
> message from a golang server as an unknown extension and alerts.  This 
> quick fix will allow the client to read and accept the extension and 
> proceed.  I believe you need golang 1.13.x to see this take place.
> This fix does not implement client-side OCSP stapling.  That will be an 
> RFE for another day.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039
> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/
> --Jamil

More information about the security-dev mailing list