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 <e...@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 <e...@zusammenkunft.net> > Gesendet: Tuesday, August 11, 2020 4:10:54 AM > An: Jamil Nimeh <jamil.j.ni...@oracle.com>; security-dev@openjdk.java.net > <security-dev@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-r...@openjdk.java.net> im Auftrag von Jamil > Nimeh <jamil.j.ni...@oracle.com> > Gesendet: Tuesday, August 11, 2020 3:11:14 AM > An: security-dev@openjdk.java.net <security-dev@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.@.. >> 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 >> 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
signature.asc
Description: Message signed with OpenPGP
