<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Amir,</p>
<p>Normally, the extension should have no impact if it cannot be
recognized by the server. It's good to be able to disable
extensions if not needed. I need to evaluate the priority of it
although. Did you have a simple test code that I can reproduce
the issue?</p>
<p>Thanks,</p>
<p>Xuelei<br>
</p>
<div class="moz-cite-prefix">On 1/20/2019 3:03 PM, Amir Khassaia
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJ3+Awf4__LA8FCBTGAeg4DZJM4apdWfWSQUWud=_vLkEdybLA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Greetings Xuelei,
<div>To follow up on this, the certificate in the connection is
a red herring and not important. It's actually a very unusual
behaviour by <a href="http://talk.google.com/" target="_blank"
moz-do-not-send="true">talk.google.com</a> endpoint to
encapsulate an error message inside a certificate.</div>
<div><br>
</div>
<div>As per the output I included: </div>
<div>
<pre style="white-space:pre-wrap;color:rgb(0,0,0)"><i>"certificate" : {
</i>><i> "version" : "v3",
</i>><i> "serial number" : "00 90 76 89 18 E9 33 93 A0",
</i>><i> "signature algorithm": "SHA256withRSA",
</i>><i> "issuer" : "CN=invalid2.invalid, OU="No SNI provided;
</i>><i> please fix your client."",
</i>><i> "not before" : "2015-01-01 11:00:00.000 AEDT",
</i>><i> "not after" : "2030-01-01 11:00:00.000 AEDT",
</i>><i> "subject" : "CN=invalid2.invalid, OU="No SNI provided;
</i>><i> please fix your client."",</i></pre>
<pre style="white-space:pre-wrap;color:rgb(0,0,0)"><i>
</i></pre>
<pre style="white-space:pre-wrap;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal">This certificate simply masks the TLS interoperability issue as an untrusted certificate issue.</span></pre>
The fact is, some of the extensions sent by JSSE are changes
to TLS 1.2 to support TLS 1.3, this however affects some
clients adversely in practice and usually JDK provides
properties to turn new enhancements off and work around such
behaviour, for the extensions I mentioned this is not provided
and hence they are always sent for client sockets unless
TLSv1.2 is not in use. </div>
<div><br>
</div>
<div>The impact to us is that upgrading to JDK11 means for some
endpoints or devices that are not 100% compliant to the spec
the security is reduced as we have to now work around to drop
connections to these to TLSv1.1 or TLS1.0 or not to move to
Java 11 at all.</div>
<div>
<pre style="white-space:pre-wrap"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">My request is simply to have all of the new extensions configurable on individual basis so that they can be turned off if needed for compatibility just like most other security enhancements that were delivered in the past.</span></font></pre>
It appears some of the issues can come from <br>
<br>
- inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these
can disabled at least<br>
<br>
-signature_algorithms_cert and supported_versions extensions
which seem to be hardcoded for TLS 1.2 (I was not able to
conclusively identify which of these caused my troubles)<br>
<br>
<a href="https://tools.ietf.org/html/rfc8446#section-1.3"
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/rfc8446#section-1.3</a> does
say that TLS 1.2 clients are affected but in an optional
manner.Just today I've encountered another Java 11 interop
issue with TLS but this time with a physical device which can
have a long shelf life yet running a simple client socket
handshake abruptly terminates the connection upon client hello
(no server_hello at all), and downgrading the JRE below 11
works fine. I'm including a trace for that as well:
<pre style="white-space:pre-wrap;color:rgb(0,0,0)">
</pre>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395
AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry =
AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE
= 137438953472<br>
<br>
javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
AEDT|ServerNameExtension.java:255|Unable to indicate server
name<br>
<br>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
AEDT|SSLExtensions.java:235|Ignore, context unavailable
extension: server_name<br>
<br>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
AEDT|SSLExtensions.java:235|Ignore, context unavailable
extension: status_request<br>
<br>
javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is
not supported by the underlying providers<br>
<br>
javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is
not supported by the underlying providers<br>
<br>
javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
AEDT|AlpnExtension.java:161|No available application protocols<br>
<br>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
AEDT|SSLExtensions.java:235|Ignore, context unavailable
extension: application_layer_protocol_negotiation<br>
<br>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
AEDT|SSLExtensions.java:235|Ignore, context unavailable
extension: status_request_v2<br>
<br>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
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 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",<br>
<br>
"session id" : "",<br>
<br>
"cipher suites" :
"[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
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,
ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512,
rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512,
dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1,
rsa_pkcs1_sha1, dsa_sha1, rsa_md5]<br>
<br>
},<br>
<br>
"signature_algorithms_cert (50)": {<br>
<br>
"signature schemes": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512,
rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512,
dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, 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
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
AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
Received fatal alert: handshake_failure (<br>
<br>
"throwable" : {<br>
<br>
javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure<br>
<br>
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)<br>
<br>
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)<br>
<br>
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)<br>
<br>
at
java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)<br>
<br>
at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)<br>
<br>
at
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)<br>
<br>
at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)<br>
<br>
at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)<br>
<br>
at
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
AEDT|SSLSocketImpl.java:1361|close the underlying socket<br>
<br>
javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
AEDT|SSLSocketImpl.java:1380|close the SSL connection
(initiative)<br>
<br>
Exception in thread "main"
javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure<br>
<br>
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)<br>
<br>
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)<br>
<br>
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)<br>
<br>
at
java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)<br>
<br>
at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)<br>
<br>
at
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)<br>
<br>
at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)<br>
<br>
at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)<br>
<br>
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)<br>
<br>
at SslSocketClient.main(SslSocketClient.kt:47)</div>
<div><br>
</div>
<div><br>
<br>
<br>
I've sent my reply earlier but neither got it posted nor
denied notification so trying again.</div>
</div>
</blockquote>
</body>
</html>