<div dir="ltr">Hi Thomas,<div>Can you confirm its tied to new extensions to TLS 1.2 client hello and whether you diagnosed which one was the problem in Lotus Notes case ?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 9:05 AM Thomas Lußnig <<a href="mailto:openjdk@suche.org">openjdk@suche.org</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,<br>
<br>
maybe two points.<br>
<br>
1) Older lotus notes server have the problem.<br>
2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2<br>
3) Maybe it would be an good idea to build an set of client hello's with <br>
different options.<br>
Or even an generator. Than you send if and check the result since <br>
the servers with problem<br>
only reply with an ssl alert. So you can check it without an ssl <br>
engine or jdk build<br>
<br>
<br>
Gruß Thomas<br>
<br>
Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:<br>
> Hi Amir,<br>
><br>
> Could you build OpenJDK by yourself? If it is doable, I could send <br>
> your a patch to disable the extension so that you can confirm if and <br>
> which 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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 <br>
>> 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, <br>
>> 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, <br>
>> 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>
>> > <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 <br>
>> (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>