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