3

We have a server which supports TLS ticket based stateless session resumption. However, when I connect to the server using openssl s_client, I still see a session ID being generated along with the TLS ticket. What is the significance of this session ID and can it be used to resume the session?

1 Answers1

1

What is the significance of this session ID and can it be used to resume the session?

You always get an ID.

You may establish more than one session with a server. The ID tells them apart. It's basically an index into a table where the server will find all necessary keys/etc. for that session.

The client can TRY session resumption by supplying the old ID during the handshake. But the server can just ignore that attempt and issue a new ID instead. Which is just what happens when that particular ID has expired from the server's ID table (session cache). It doesn't cost the client anything extra to try resumption.

Further reading

Update 1. Empty IDs

I don't really understand this. Maybe some SE-user can expand on this.

I don't really understand the interaction when both IDs and Tickets are enabled. So I decided to read that section in my copy of "Bulletproof SSL and TLS":
(quote is from Chapter 2. Protocol | Extensions | Session Tickets)

Note
When a server decides to use session tickets for session resumption, it sends back an empty session ID field (in its ServerHello message). At this point, the session does not have a unique identifier. However, the ticket specification allows the client to select and submit a session ID (in its ClientHello) in a subsequent handshake that uses the ticket. A server that accepts the ticket must also respond with the same session ID. This is why the session ID appears in the TLS web server logs even when session tickets are used as the session-resumption mechanism.

And having read this, now I'm not so sure anymore that I actually understand the concept of the session ID.

Anyway, the relevant section from the session ticket RFC is 3.4. Interaction with TLS Session ID.

And this seems to say that session IDs either don't exist or don't matter when tickets are in use. Dunno.

Community
  • 1
StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
  • I think I should clarify my question. If the server issues a TLS ticket for a session, can it also resume that session using the issued session-ID? I would think that the server would support one or the other but not _both_ –  Oct 31 '15 at 07:28
  • No. It's actually both. For backwards compatibility. See links. – StackzOfZtuff Oct 31 '15 at 07:50
  • 1
    I did see the links. They seem to suggest if a client supports ticket-based resumption, the server issues a ticket. If it doesn't, the server falls back to session-ID caching. So it's either-or but not both. If a client supports tickets, the server will issue one and will not store state in the session cache (stateless resumption) because the ticket itself can be used to re-create the entire session. In that scenario, the generated session-ID may not be useful for resuming the session. Correct? –  Oct 31 '15 at 10:19
  • Oh, I understand now. Right. I can only speculate: If the tickets are meant to relieve the server storage, then should mean that servers that have actually issued a ticket will eject such client's session IDs from the session cache earlier than otherwise. But I don't know how IIS/Apache/Nginx actually do this in practice. Sorry. – StackzOfZtuff Oct 31 '15 at 12:13