[TLS-backport8] Does TLSv1.3 work with www.google.com

Alexey Bakhtin alexey at azul.com
Tue Aug 11 10:45:53 UTC 2020


Hello Bernd,

The difference between Java8u TLSv1.3 backport and OpenJSSE is TLS_CHACHA20_POLY1305_SHA256 cipher suite support.
I've found, that connection to google.com succeeds in case of ClientHello includes Chacha20-Poly1305 in the list of supported cipher suites, even if status request is disabled.
Jdk11 and Java8u TLSv1.3 backport does not support ChaCha20-Poly1305 cipher suites, so connection fails w/o status request.

Regards
Alexey

> On 11 Aug 2020, at 05:18, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 
> Jamil, just a folllw up, I noticed in the bug comets that there are multiple conditions where boringSSL fails, seems like OpenJSSE somehow does not trigger the fingerprint match w/ and w/o status request.
> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> Von: Bernd Eckenfels <ecki at zusammenkunft.net>
> Gesendet: Tuesday, August 11, 2020 4:10:54 AM
> An: Jamil Nimeh <jamil.j.nimeh at oracle.com>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com
> 
> Hello Jamil,
> 
> Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE).
> 
> There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension is sent in ClientHello. I naturally disabled it and I can see in the debug log that the extension is no longer requested - HOWEVER the handshake with google.com still succeeds with OpenJSSE. WAT? :)
> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Jamil Nimeh <jamil.j.nimeh at oracle.com>
> Gesendet: Tuesday, August 11, 2020 3:11:14 AM
> An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com
> 
> Hmmm, looks a lot like this issue: https://bugs.openjdk.java.net/browse/JDK-8241360.  What happens if you run it with -Djdk.tls.client.enableStatusRequestExtension=true?  That should get you past it.  This is mentioned in the release notes for 8u261:
> 
> https://www.oracle.com/java/technologies/javase/8u261-relnotes.html
> 
> --Jamil
> 
> On 8/10/2020 5:49 PM, Bernd wrote:
>> Hallo,
>> 
>> is the upcoming Java8u TLS backport supposed to work with "-Djdk.tls.client.protocols=TLSv1.3" when connecting to https://www.google.com?
>> 
>> I get an alert when I try to HttpsURLConnection.open to it. This happens with the Zulu port of this feature as well as the 8u261GA from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher.
>> 
>> The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it does handshake correctly with Google (so only difference i can see is an additional OCSP request and chacha cipher which is not picked).
>> 
>> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 CEST|Logger.java:765|Produced ClientHello handshake message (
>> "ClientHello": {
>>   "client version"      : "TLSv1.2",
>>   "random"              : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1",
>>   "session id"          : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8",
>>   "cipher suites"       : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302)]",
>>   "compression methods" : "00",
>>   "extensions"          : [
>>     "server_name (0)": {
>>       type=host_name (0), value=www.google.com
>>     },
>>     "supported_groups (10)": {
>>       "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
>>     },
>>     "signature_algorithms (13)": {
>>       "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_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, ecdsa_sha1, rsa_pkcs1_sha1]
>>     },
>>     "signature_algorithms_cert (50)": {
>>       "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_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, ecdsa_sha1, rsa_pkcs1_sha1]
>>     },
>>     "supported_versions (43)": {
>>       "versions": [TLSv1.3]
>>     },
>>     "psk_key_exchange_modes (45)": {
>>       "ke_modes": [psk_dhe_ke]
>>     },
>>     "key_share (51)": {
>>       "client_shares": [
>>         {
>>           "named group": secp256r1
>>           "key_exchange": {
>>             0000: 04 A4 C2 58 EF 8B 62 3D   47 C4 21 FE 7D 4A 85 2B  ...X..b=G.!..J.+
>>             0010: AE 99 7D 3C 30 08 F4 00   F3 B0 A9 17 DE 0E B1 16  ...<0...........
>>             0020: 0D 45 46 87 42 B0 83 68   FB 15 E9 79 D2 40 8C DA  .EF.B..h...y. at ..
>>             0030: 38 FF 76 52 1D 40 10 A0   BE 39 75 8B 79 F0 CD A1  8.vR. at ...9u.y...
>>             0040: E1
>>           }
>>         },
>>       ]
>>     }
>>   ]
>> }
>> )
>> ...
>> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 CEST|Logger.java:765|Received alert message (
>> "Alert": {
>>   "level"      : "fatal",
>>   "description": "protocol_version"
>> }
>> )
>> 
>> 
>> 
>> Gruss
>> Bernd

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200811/6eae14d9/signature.asc>


More information about the security-dev mailing list