Apache Tomcat has the ability to use the TLS Session ID instead of a session cookie or JSESSIONID in the querystring. My site is HTTPS Everywhere.

This seems useful in that I don't have to worry about session cookie theft, and can use sessions for user agents that don't do cookies.

Am I immune to Session Hijacking / Session Fixation here?

Any other issues to be concerned about?

  • Incidentally, I think FIDO U2F and UAF both use TLS SessionID Commented Feb 20, 2015 at 18:52

2 Answers 2


SSL Session IDs are plaintext and visible to anyone watching the bits fly across the network. If you're worried about hijacking, this would not be a good idea.


I'm asuming you are referring to the TLS Session ID as specified in RFC 4507

No, I don't think this will give you what you need. The TLS Session ID is a ticket provided by the server to the client which will allow the client to resume a session at a latter time (i.e. after existing session has ceased). This is focused at the TLS layer, which you can think of as a layer below your application layer. The TLS layer is all about establishing the secure connection and knows nothing about your application level.

When you first connect to a TLS enabled service, there is a handshake process between the server and the client which is used to establish the secure connection. With the use of the session ID, the handshake process can be reduced in subsequent connections - by providing a valid session ID, the client is essentially saying "Hey, lets hook up again and use the same encryption keys etc that we used last time. The server may say "Hey cool, lets go" or it may say, "Sorry, been too long, we need to re-negotiate".

As this is a layer below your application, the TLS session ID doesn't know if you are authenticated with the application or what your authorisation level is. Normally, this will only occur after the TLS connection has been negotiated and established. You cannot add this information to the TLS session ID as this is an encrypted value generated by the server side TLS layer. This also means your application cannot determine the user credentials from the TLS session ID.

If your users need to be authenticated and authorised, you really need to manage that in an application level session or cookie, you need to be able to verify it hasn't been modified and you need to include additional protection, such as CSRF protection tokens and you need to verify all of this on every request.

  • 1
    Actually 4507 ticket (encrypted and sent to and cached by the client) is an alternative to session-id; session-id identifies session info cached at both endpoints (client and server). See tools.ietf.org/html/rfc5246#section- et seq, essentially unchanged in prior versions back to SSL3 (4346, 2246, 6101). And as @Sean says it is in clear, at least on the initial handshake. Commented Feb 22, 2015 at 22:42
  • Web App Sessions seem to work fine using the TLS Session ID. However, if the id is sent in the clear, that's not what I want :) Thx Commented Feb 22, 2015 at 23:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .