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.ni...@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-r...@openjdk.java.net> >> <mailto:security-dev-r...@openjdk.java.net> im Auftrag von Jamil Nimeh >> <jamil.j.ni...@oracle.com> <mailto:jamil.j.ni...@oracle.com> >> Gesendet: Tuesday, August 11, 2020 3:11:14 AM >> An: security-dev@openjdk.java.net <mailto:security-dev@openjdk.java.net> >> <security-dev@openjdk.java.net> <mailto:security-dev@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.@.. >>> 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 >>> 8.vR.@...9u.y <mailto:8.vR.@...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
