Hi Thomas, 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 ?
On Thu, Feb 14, 2019 at 9:05 AM Thomas Lußnig <open...@suche.org> wrote: > Hi, > > maybe two points. > > 1) Older lotus notes server have the problem. > 2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2 > 3) Maybe it would be an good idea to build an set of client hello's with > different options. > Or even an generator. Than you send if and check the result since > the servers with problem > only reply with an ssl alert. So you can check it without an ssl > engine or jdk build > > > Gruß Thomas > > Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan: > > Hi Amir, > > > > Could you build OpenJDK by yourself? If it is doable, I could send > > your a patch to disable the extension so that you can confirm if and > > which extension is the underlying problem. > > > > Thanks, > > Xuelei > > > > > > On 2/13/2019 1:16 PM, Amir Khassaia wrote: > >> Hi Xuelei, > >> There were 2 distinct cases of change of behaviour. > >> > >> * The "CN=invalid2.invalid, OU="No SNI provided" reliably works > >> without SNI in Java 8 but is indeed fixed by having an SNI included > >> which perhaps was needed all along. This one is reported by XMPP/TLS > >> connection from talk.google.com:5222 <http://talk.google.com:5222> > >> * The aborted handshake case (client_hello traces that I've provided) > >> this happened with a hardware device which was replicable with an > >> SSL socket handshake program that I referenced in the gist. > >> Unfortunately replication requires a specific device model so it > >> wont be possible to see it for yourself. The workaround there was to > >> either downgrade JRE to < 11 or to switch JRE globally to use TLS > >> 1.0 or TLS 1.1 via the system property. This is where your proposed > >> enhancement will be of great help as it will allow a per connection > >> type decision. > >> > >> > >> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei....@oracle.com > >> <mailto:xuelei....@oracle.com>> wrote: > >> > >> Hi Amir, > >> > >> It should be rare now the a TLS vendor cannot ignore unknown > >> extensions. > >> > >> > "issuer": "CN=invalid2.invalid, OU="No SNI provided; > >> > please fix your client."", > >> The error message encapsulated in the certificate does not sound > >> right > >> to me. Is it caused by the absence of SNI extension? > >> > >> Did you have a test case that I can reproduce the problem? > >> > >> Thanks & Regards, > >> Xuelei > >> > >> > >> On 1/7/2019 9:27 PM, Amir Khassaia wrote: > >> > Xuelei, > >> > The certificate in the connection is a red herring and not > >> important. > >> > It's actually a very unusual behaviour by talk.google.com > >> <http://talk.google.com> > >> > <http://talk.google.com> endpoint to encapsulate an error > message > >> inside > >> > a certificate. > >> > > >> > As per the output I included: > >> > > >> > /"certificate" : { />/ "version" : "v3", />/ > >> "serial number" : "00 90 76 89 18 E9 33 93 A0", />/ > >> "signature algorithm": "SHA256withRSA", />/ "issuer" > >> : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your > >> client."", />/ "not before" : "2015-01-01 11:00:00.000 > >> AEDT", />/ "not after" : "2030-01-01 11:00:00.000 AEDT", > >> />/ "subject" : "CN=invalid2.invalid, OU="No SNI > >> provided; />/please fix your client."",/ > >> > > >> > / > >> > / > >> > > >> > This certificate simply masks the TLS interoperability issue > >> as an > >> > untrusted certificate issue. > >> > > >> > 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. > >> > > >> > 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. > >> > > >> > 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. > >> > > >> > It appears some of the issues can come from > >> > > >> > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can > >> > disabled at least > >> > > >> > -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) > >> > > >> > https://tools.ietf.org/html/rfc8446#section-1.3 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: > >> > > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395 > >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = > >> AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE > >> =137438953472 > >> > > >> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 > >> > AEDT|ServerNameExtension.java:255|Unable to indicate server name > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable > >> extension: > >> > server_name > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable > >> extension: > >> > status_request > >> > > >> > 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 > >> > > >> > 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 > >> > > >> > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 > >> > AEDT|AlpnExtension.java:161|No available application protocols > >> > > >> > 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 > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 > >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable > >> extension: > >> > status_request_v2 > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 > >> > AEDT|ClientHello.java:651|Produced ClientHello handshake > >> message ( > >> > > >> > "ClientHello": { > >> > > >> > "client version" : "TLSv1.2", > >> > > >> > "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", > >> > > >> > "session id" : "", > >> > > >> > "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)]", > >> > > >> > "compression methods" : "00", > >> > > >> > "extensions" : [ > >> > > >> > "supported_groups (10)": { > >> > > >> > "versions": [secp256r1, secp384r1, secp521r1, secp160k1] > >> > > >> > }, > >> > > >> > "ec_point_formats (11)": { > >> > > >> > "formats": [uncompressed] > >> > > >> > }, > >> > > >> > "signature_algorithms (13)": { > >> > > >> > "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] > >> > > >> > }, > >> > > >> > "signature_algorithms_cert (50)": { > >> > > >> > "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] > >> > > >> > }, > >> > > >> > "extended_master_secret (23)": { > >> > > >> > <empty> > >> > > >> > }, > >> > > >> > "supported_versions (43)": { > >> > > >> > "versions": [TLSv1.2, TLSv1.1] > >> > > >> > }, > >> > > >> > "renegotiation_info (65,281)": { > >> > > >> > "renegotiated connection": [<no renegotiated connection>] > >> > > >> > } > >> > > >> > ] > >> > > >> > } > >> > > >> > ) > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 > >> > AEDT|Alert.java:232|Received alert message ( > >> > > >> > "Alert": { > >> > > >> > "level" : "fatal", > >> > > >> > "description": "handshake_failure" > >> > > >> > } > >> > > >> > ) > >> > > >> > 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 ( > >> > > >> > "throwable" : { > >> > > >> > javax.net.ssl.SSLHandshakeException: Received fatal alert: > >> > handshake_failure > >> > > >> > at > >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > >> > > >> > at > >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > >> > > >> > at > >> > > >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > >> > > >> > at > >> > > >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > >> > > >> > at > >> > > >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > >> > > >> > at SslSocketClient.main(SslSocketClient.kt:47)} > >> > > >> > > >> > ) > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > >> > AEDT|SSLSocketImpl.java:1361|close the underlying socket > >> > > >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > >> > AEDT|SSLSocketImpl.java:1380|close the SSL connection > >> (initiative) > >> > > >> > Exception in thread "main" javax.net.ssl.SSLHandshakeException: > >> Received > >> > fatal alert: handshake_failure > >> > > >> > at > >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > >> > > >> > at > >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > >> > > >> > at > >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > >> > > >> > at > >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > >> > > >> > at > >> > > >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > >> > > >> > at > >> > > >> > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > >> > > >> > at SslSocketClient.main(SslSocketClient.kt:47) > >> > > >> > > >> > > >> > > >> >
