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

Tue Aug 11 06:48:06 UTC 2020

Just FTW I think they still enable the TLS1.3 detection logic via their BoringSSL usage just like others noted:

https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_set_jdk11_workaround <https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_set_jdk11_workaround>

Bye
Norman

> On 11. Aug 2020, at 04:23, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
> 
> 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 <http://bernd.eckenfels.net/>
>> Von: security-dev <security-dev-retn at openjdk.java.net> <mailto:security-dev-retn at openjdk.java.net> im Auftrag von Jamil Nimeh <jamil.j.nimeh at oracle.com> <mailto:jamil.j.nimeh at oracle.com>
>> Gesendet: Tuesday, August 11, 2020 3:11:14 AM
>> An: security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net> <security-dev at openjdk.java.net> <mailto:security-dev at openjdk.java.net>
>> Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com <http://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 <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 tohttps://www.google.com <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/20200811/ba1ee7df/attachment.htm>