Not possible to disable new TLS extensions for TLS 1.2 connections

Tue Jan 8 05:28:03 UTC 2019

Xuelei,
The certificate in the connection is a red herring and not important. It's
actually a very unusual behaviour by 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-08 13:40:14.395
AEDT|SSLCipher.java:437|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding
KeyUpdate 2^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/20190108/c42211de/attachment.htm>