SSLSocket session resumption not working with TLS 1.3 and 11+27
Adam Petcher
adam.petcher at oracle.com
Fri Aug 24 18:54:05 UTC 2018
Thanks for testing this. I developed most of the NewSessionTicket/PSK
code. See below for my comments.
On 8/23/2018 3:28 PM, Simone Bordet wrote:
> Hi,
>
> The code below reproduces a bug where session resumption is tested.
> Turns out that session resumption does happen on the client and on the
> server, but on the client the session id is not replaced with the
> resumed session id (while it is on the server).
>
> The code prints:
>
> session1 = Session(1535051727187|TLS_AES_128_GCM_SHA256) - [29, -38, ...]
> session2 = Session(1535051727187|TLS_AES_128_GCM_SHA256) - [11, -20, ...]
>
> where it can be seen that the second session has the same creationTime
> as the first, but different session id (the array).
Just to be clear: are you saying that a short handshake is happening in
all cases, or are there some cases where a full handshake (including
Certificate and CertificateVerify) is used where you would expect a
short handshake? The fact that the session ID is different is expected,
and it is a result of the fact that sessions are managed differently in
the TLS 1.3 implementation. You can no longer use session IDs to
determine whether a full handshake was used. Also sessions are managed
differently in the client and server code, so you should expect
different behavior in client/server with respect to session IDs.
> About the code below, note how it is necessary to attempt a read after
> the first handshake to read the NewSessionTicket post-handshake
> message that is otherwise not consumed by the client. This was not
> necessary before.
> Scenarios where clients don't read from the server (or where many
> clients are created before one starts reading) will have a harder time
> to use session resumption.
This is also expected behavior in the current TLS 1.3 implementation. I
created a ticket[1] to document your concerns and capture a few
potential ways to improve things.
[1] https://bugs.openjdk.java.net/browse/JDK-8209953
More information about the security-dev
mailing list