Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8211806

TLS 1.3 handshake server name indication is missing on a session resume

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b17
    • Verification:
      Verified

      Backports

        Description

        A customer showed me a case where a TLSv1.3 handshake is failing, but passes on TLSv1.2 on JDK 11. It also doesn't fail in TLSv1.2 on JDK 10.

        Customer is primarily using: URL.openConnection()/getInputStream()

        In a simple connection, I am seeing the right server_name extension for <hostname> going out. The certificates received from the server are also for <hostname>:

          "extensions" : [
            "server_name (0)": {
              type=host_name (0), value=<hostname>
            },
        ...deleted...
        javax.net.ssl|DEBUG|01|main|2018-10-05 14:41:28.941 PDT|CertificateMessage.java:1148|Consuming server Certificate handshake message (
        "Certificate": {
          "certificate_request_context": "",
          "certificate_list": [
          {
            "certificate" : {
              "issuer" : "CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US",
              "subject" : "CN=<hostname>",

        with alternate names for:

                  SubjectAlternativeName [
                    DNSName: <hostname>
                    DNSName: www.&lt;hostname>
                  ]

        However, in the debug log he showed me, I didn't see the server_name extension going out in the second connection, and noticed this in the debug log:

        javax.net.ssl|DEBUG|81|Thread-78|2018-09-27 18:20:46.303 PDT|Utilities.java:73|the previous server name in SNI (type=host_name (0), value=<hostname>) was replaced with (type=host_name (0), value=<hostname>)

        and the certificate received was for:

              "subject" : "CN=*.<hostname2>,

        Are they running <hostname> on a virtual server named <hostname2>?

        So something about the server name indication seems to be going haywire.

        That's my best guess.

        ----some additional notes----

        It appears to be a race condition between how connections are created, as it doesn't always happen. Sometimes the app will work fine, but othertimes it's almost immediate. Outputting "all" debug information reduced the frequency of occurrence, but would eventually happen.

        There is currently not a simple reproducible test case. But the two error logs show the same error, one from the debug output, and one from the wireshark output.
         
        See the later comments for additional information.

          Attachments

          1. javacli-fail.pcap.gz
            17 kB
          2. javacli-fail.txt.gz
            8 kB
          3. JDK-8211806.zip
            19.47 MB

            Issue Links

              Activity

                People

                • Assignee:
                  jnimeh Jamil Nimeh
                  Reporter:
                  wetmore Bradford Wetmore
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: