Not possible to disable new TLS extensions for TLS 1.2 connections

Xuelei Fan xuelei.fan at oracle.com
Sun Jan 20 23:36:44 UTC 2019


Hi Amir,

Normally, the extension should have no impact if it cannot be recognized 
by the server.   It's good to be able to disable extensions if not 
needed.   I need to evaluate the priority of it although.  Did you have 
a simple test code that I can reproduce the issue?

Thanks,

Xuelei

On 1/20/2019 3:03 PM, Amir Khassaia wrote:
> Greetings Xuelei,
> To follow up on this, 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/> 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)
>
>
>
>
> I've sent my reply earlier but neither got it posted nor denied 
> notification so trying again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190120/7e311e33/attachment-0001.html>


More information about the security-dev mailing list