<div dir="ltr">Unfortunately I no longer have the device that replicates the problem :( and other similar ones never showed in the first place.<div>Traditionally I would make TLS handshakes stay identical across JDK versions to ensure compatibility as working with various devices and vendors would show up a multitude of ways a handshake would fail, including ones where handshake succeeds but application data encryption fails later etc.</div><div>In each of these JDK tuning would be able to make the handshake "compatible" with a given device. In this case it could be made almost identical with the exception of the extensions listed. I can send you wireshark PCAPs if needed from the session with the device but they will really just show the same information as already listed.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 8:44 AM Xuelei Fan <<a href="mailto:xuelei.fan@oracle.com">xuelei.fan@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Amir,<br>
<br>
Could you build OpenJDK by yourself? If it is doable, I could send your <br>
a patch to disable the extension so that you can confirm if and which <br>
extension is the underlying problem.<br>
<br>
Thanks,<br>
Xuelei<br>
<br>
<br>
On 2/13/2019 1:16 PM, Amir Khassaia wrote:<br>
> Hi Xuelei,<br>
> There were 2 distinct cases of change of behaviour.<br>
> <br>
> * The "CN=invalid2.invalid, OU="No SNI provided" reliably works<br>
> without SNI in Java 8 but is indeed fixed by having an SNI included<br>
> which perhaps was needed all along. This one is reported by XMPP/TLS<br>
> connection from <a href="http://talk.google.com:5222" rel="noreferrer" target="_blank">talk.google.com:5222</a> <<a href="http://talk.google.com:5222" rel="noreferrer" target="_blank">http://talk.google.com:5222</a>><br>
> * The aborted handshake case (client_hello traces that I've provided)<br>
> this happened with a hardware device which was replicable with an<br>
> SSL socket handshake program that I referenced in the gist.<br>
> Unfortunately replication requires a specific device model so it<br>
> wont be possible to see it for yourself. The workaround there was to<br>
> either downgrade JRE to < 11 or to switch JRE globally to use TLS<br>
> 1.0 or TLS 1.1 via the system property. This is where your proposed<br>
> enhancement will be of great help as it will allow a per connection<br>
> type decision.<br>
> <br>
> <br>
> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a> <br>
> <mailto:<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a>>> wrote:<br>
> <br>
> Hi Amir,<br>
> <br>
> It should be rare now the a TLS vendor cannot ignore unknown extensions.<br>
> <br>
> > "issuer": "CN=invalid2.invalid, OU="No SNI provided;<br>
> > please fix your client."",<br>
> The error message encapsulated in the certificate does not sound right<br>
> to me. Is it caused by the absence of SNI extension?<br>
> <br>
> Did you have a test case that I can reproduce the problem?<br>
> <br>
> Thanks & Regards,<br>
> Xuelei<br>
> <br>
> <br>
> On 1/7/2019 9:27 PM, Amir Khassaia wrote:<br>
> > Xuelei,<br>
> > The certificate in the connection is a red herring and not<br>
> important.<br>
> > It's actually a very unusual behaviour by <a href="http://talk.google.com" rel="noreferrer" target="_blank">talk.google.com</a><br>
> <<a href="http://talk.google.com" rel="noreferrer" target="_blank">http://talk.google.com</a>><br>
> > <<a href="http://talk.google.com" rel="noreferrer" target="_blank">http://talk.google.com</a>> endpoint to encapsulate an error message<br>
> inside<br>
> > a certificate.<br>
> ><br>
> > As per the output I included:<br>
> ><br>
> > /"certificate" : { />/ "version" : "v3", />/ <br>
> "serial number" : "00 90 76 89 18 E9 33 93 A0", />/ <br>
> "signature algorithm": "SHA256withRSA", />/ "issuer" <br>
> : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your<br>
> client."", />/ "not before" : "2015-01-01 11:00:00.000<br>
> AEDT", />/ "not after" : "2030-01-01 11:00:00.000 AEDT",<br>
> />/ "subject" : "CN=invalid2.invalid, OU="No SNI<br>
> provided; />/please fix your client."",/<br>
> ><br>
> > /<br>
> > /<br>
> ><br>
> > This certificate simply masks the TLS interoperability issue as an<br>
> > untrusted certificate issue.<br>
> ><br>
> > The fact is, some of the extensions sent by JSSE are changes to<br>
> TLS 1.2<br>
> > to support TLS 1.3, this however affects some clients adversely in<br>
> > practice and usually JDK provides properties to turn new<br>
> enhancements<br>
> > off and work around such behaviour, for the extensions I<br>
> mentioned this<br>
> > is not provided and hence they are always sent for client sockets<br>
> unless<br>
> > TLSv1.2 is not in use.<br>
> ><br>
> > The impact to us is that upgrading to JDK11 means for some<br>
> endpoints or<br>
> > devices that are not 100% compliant to the spec the security is<br>
> reduced<br>
> > as we have to now work around to drop connections to these to<br>
> TLSv1.1 or<br>
> > TLS1.0 or not to move to Java 11 at all.<br>
> ><br>
> > My request is simply to have all of the new extensions<br>
> configurable on<br>
> > individual basis so that they can be turned off if needed for<br>
> > compatibility just like most other security enhancements that were<br>
> > delivered in the past.<br>
> ><br>
> > It appears some of the issues can come from<br>
> ><br>
> > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can<br>
> > disabled at least<br>
> ><br>
> > -signature_algorithms_cert and supported_versions extensions<br>
> which seem<br>
> > to be hardcoded for TLS 1.2 (I was not able to conclusively identify<br>
> > which of these caused my troubles)<br>
> ><br>
> > <a href="https://tools.ietf.org/html/rfc8446#section-1.3" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc8446#section-1.3</a> does say that TLS<br>
> 1.2<br>
> > clients are affected but in an optional manner.Just today I've<br>
> > encountered another Java 11 interop issue with TLS but this time<br>
> with a<br>
> > physical device which can have a long shelf life yet running a<br>
> simple<br>
> > client socket handshake abruptly terminates the connection upon<br>
> client<br>
> > hello (no server_hello at all), and downgrading the JRE below 11<br>
> works<br>
> > fine. I'm including a trace for that as well:<br>
> ><br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395 <br>
> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry =<br>
> AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE<br>
> =137438953472<br>
> ><br>
> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433<br>
> > AEDT|ServerNameExtension.java:255|Unable to indicate server name<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433<br>
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:<br>
> > server_name<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433<br>
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:<br>
> > status_request<br>
> ><br>
> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443<br>
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not<br>
> > supported by the underlying providers<br>
> ><br>
> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444<br>
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not<br>
> > supported by the underlying providers<br>
> ><br>
> > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449<br>
> > AEDT|AlpnExtension.java:161|No available application protocols<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449<br>
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:<br>
> > application_layer_protocol_negotiation<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450<br>
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:<br>
> > status_request_v2<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453<br>
> > AEDT|ClientHello.java:651|Produced ClientHello handshake message (<br>
> ><br>
> > "ClientHello": {<br>
> ><br>
> > "client version" : "TLSv1.2",<br>
> ><br>
> > "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24<br>
> 7F 34 3D<br>
> > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",<br>
> ><br>
> > "session id" : "",<br>
> ><br>
> > "cipher suites" :<br>
> > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),<br>
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),<br>
> > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),<br>
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),<br>
> > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",<br>
> ><br>
> > "compression methods" : "00",<br>
> ><br>
> > "extensions" : [<br>
> ><br>
> > "supported_groups (10)": {<br>
> ><br>
> > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]<br>
> ><br>
> > },<br>
> ><br>
> > "ec_point_formats (11)": {<br>
> ><br>
> > "formats": [uncompressed]<br>
> ><br>
> > },<br>
> ><br>
> > "signature_algorithms (13)": {<br>
> ><br>
> > "signature schemes": [ecdsa_secp256r1_sha256,<br>
> ecdsa_secp384r1_sha384,<br>
> > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,<br>
> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,<br>
> > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,<br>
> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224,<br>
> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]<br>
> ><br>
> > },<br>
> ><br>
> > "signature_algorithms_cert (50)": {<br>
> ><br>
> > "signature schemes": [ecdsa_secp256r1_sha256,<br>
> ecdsa_secp384r1_sha384,<br>
> > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,<br>
> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,<br>
> > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,<br>
> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224,<br>
> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]<br>
> ><br>
> > },<br>
> ><br>
> > "extended_master_secret (23)": {<br>
> ><br>
> > <empty><br>
> ><br>
> > },<br>
> ><br>
> > "supported_versions (43)": {<br>
> ><br>
> > "versions": [TLSv1.2, TLSv1.1]<br>
> ><br>
> > },<br>
> ><br>
> > "renegotiation_info (65,281)": {<br>
> ><br>
> > "renegotiated connection": [<no renegotiated connection>]<br>
> ><br>
> > }<br>
> ><br>
> > ]<br>
> ><br>
> > }<br>
> ><br>
> > )<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455<br>
> > AEDT|Alert.java:232|Received alert message (<br>
> ><br>
> > "Alert": {<br>
> ><br>
> > "level" : "fatal",<br>
> ><br>
> > "description": "handshake_failure"<br>
> ><br>
> > }<br>
> ><br>
> > )<br>
> ><br>
> > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456<br>
> > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):<br>
> Received fatal<br>
> > alert: handshake_failure (<br>
> ><br>
> > "throwable" : {<br>
> ><br>
> > javax.net.ssl.SSLHandshakeException: Received fatal alert:<br>
> > handshake_failure<br>
> ><br>
> > at<br>
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)<br>
> ><br>
> > at<br>
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)<br>
> ><br>
> > at<br>
> > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)<br>
> ><br>
> > at SslSocketClient.main(SslSocketClient.kt:47)}<br>
> ><br>
> ><br>
> > )<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457<br>
> > AEDT|SSLSocketImpl.java:1361|close the underlying socket<br>
> ><br>
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457<br>
> > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative)<br>
> ><br>
> > Exception in thread "main" javax.net.ssl.SSLHandshakeException:<br>
> Received<br>
> > fatal alert: handshake_failure<br>
> ><br>
> > at<br>
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)<br>
> ><br>
> > at<br>
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)<br>
> ><br>
> > at<br>
> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)<br>
> ><br>
> > at<br>
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)<br>
> ><br>
> > at<br>
> ><br>
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)<br>
> ><br>
> > at SslSocketClient.main(SslSocketClient.kt:47)<br>
> ><br>
> ><br>
> ><br>
> ><br>
> <br>
</blockquote></div>