Not possible to disable new TLS extensions for TLS 1.2 connections
Amir Khassaia
amir.khassaia at gmail.com
Wed Feb 13 22:08:22 UTC 2019
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 <openjdk at 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.fan at oracle.com
> >> <mailto:xuelei.fan at 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)
> >> >
> >> >
> >> >
> >> >
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190214/1a808acd/attachment.htm>
More information about the security-dev
mailing list