Not possible to disable new TLS extensions for TLS 1.2 connections

Xuelei Fan xuelei.fan at oracle.com
Wed Feb 13 21:44:31 UTC 2019


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)
>      >
>      >
>      >
>      >
> 


More information about the security-dev mailing list