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

Tue Aug 11 02:23:32 UTC 2020

Hi Bernd,

Without seeing the respective traces it is hard to know for certain, but 
I can tell you that BoringSSL looks for a specific "fingerprint" in the 
client hello which it attributes to the original JDK 11 client hello.  
They did this to work around specific bugs in the initial TLS 1.3 
implementation released with JDK 11.

If the client hello is structured such that it doesn't match the 
fingerprint then things proceed with no issues.  There are many ways to 
change the fingerprint.  It can even be accomplished by using the 
identical set of extensions that cause the failure, but ordering them 
differently.  I had more than a few "WAT?" moments getting my head 
around that when we were characterizing this issue back in April.  :)

If we were to look at the client hellos from that Zulu OpenJSSE 
provider, I'm sure we could identify the element that changes the 
fingerprint such that it works.

--Jamil

On 8/10/2020 7:10 PM, Bernd Eckenfels wrote:
> 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 
> <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 <http://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 <mailto: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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200810/6d047583/attachment.htm>