Not possible to disable new TLS extensions for TLS 1.2 connections
Amir Khassaia
amir.khassaia at gmail.com
Wed Feb 13 21:57:20 UTC 2019
Unfortunately I no longer have the device that replicates the problem :(
and other similar ones never showed in the first place.
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.
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.
On Thu, Feb 14, 2019 at 8:44 AM Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 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/9b64c06a/attachment.htm>
More information about the security-dev
mailing list