SSLSocket session resumption not working with TLS 1.3 and 11+27

[Simone Bordet]

Hi,

On Fri, Aug 24, 2018 at 8:54 PM Adam Petcher <adam.petcher at oracle.com> wrote:
> 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,

I have not tested all cases, but a short handshake happens (on the
second connection) with the code I posted.

> or are there some cases where a full handshake (including
> Certificate and CertificateVerify) is used where you would expect a
> short handshake?

I have not seen this, but as I said, I have not tested all cases, such
as client authentication, etc.

 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.

However, on the server-side the session ID is the same, so I am
confused by the fact that on the client the session has been resumed,
but it has a different ID.

> You can no longer use session IDs to
> determine whether a full handshake was used.

Why not? I could not find a section in the TLS 1.3 RFC that mandates
that resumed session IDs must be different.
We have had in the past Jetty users that relied on this feature
heavily to confirm that they were actually resuming sessions - for
performance reasons.
Comparing SSLSession.creationTime seems more brittle.

> 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.

Indeed. Is this an implementation detail, or it's mandated by the RFC?

> > 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

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz