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
