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
