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

Bernd Eckenfels ecki at zusammenkunft.net
Tue Aug 11 02:18:43 UTC 2020


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<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/e869329f/attachment.htm>


More information about the security-dev mailing list