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

Adam Petcher adam.petcher at oracle.com
Mon Aug 27 12:52:30 UTC 2018


On 8/24/2018 4:08 PM, Simone Bordet wrote:

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

When the client receives a NewSessionTicket message, it copies the 
current SSLSession and stores the copy in the cache. When you connect 
for the second time, this copy is the session that is resumed. The copy 
does not have the same ID as the initial session. This implementation 
may seem strange, but it is a simple way to allow the client to receive 
multiple NewSessionTicket messages and store them all (as SSLSession 
objects in the cache).

The server does something very similar when it sends a NewSessionTicket 
message. So I'm surprised that you are seeing the session ID being 
reused on the server. This isn't a problem on it's own, but if you send 
me your code that checks server session IDs, then I'll investigate it.

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

Session IDs are obsolete in TLS 1.3, so there are no requirements 
stating that they need to be the same or different for resumed session. 
They are different in our implementation because I was concerned about 
issues that would arise from having two different sessions with the same 
ID.

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

I agree that looking at creation time is not a great solution, and we 
should probably have a better way to determine whether the session was 
resumed in the API. If you tell me a bit more about your requirements, 
then I can put them in a ticket. For example, do you also need to know 
which PSK mode was used (PSK-only or PSK+DHE)? Also do you need to be 
able to influence the resumption modes (e.g. "set up a connection using 
PSK-only")?

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

Everything related to session IDs in TLS 1.3 (once version 1.3 has been 
negotiated) is an implementation detail.



More information about the security-dev mailing list