TLS 1.3 handshake fails if server_name doesn't match resuming session

XMLWordPrintable

    • b18
    • Verified

        Under certain circumstances the TLS 1.3 handshake may fail: the client sends a pre_shared_key extension, the server processes it, later the server decides not to resume the session, but it still sends its pre_shared_key extension. As a result, the client's handshake keys computed using the PSK do not match the server's, because the server does not use the PSK.

        This can happen when the original session was established with a SNIMatcher and the resumption was performed without a SNIMatcher.

        Reproducer attached. It performs 2 handshakes using the same SSLContext. The first handshake succeeds, the second aborts with "Tag mismatch". Expected result: both handshakes finish successfully.

        Possible solution: make PreSharedKeyExtension.SHPreSharedKeyProducer return null if shc.isResumption is false.

          1. BadResumption.zip
            5 kB

              Assignee:
              Jaikiran Pai
              Reporter:
              Daniel Jelinski
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: