[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