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.
