In what cases will server send empty session id during TLS handshake?

1.5k views Asked by At

I want to uses the SSL session ID for session stickiness and session persistence on loadbalancer. The SSL handshake process is successful. But i see in tcp traces server empty session id during TLS handshake. I want to know how to enable SSL session ID on application server. Using apache-tomcat for my application.

Wireshare captures

1

There are 1 answers

0
dave_thompson_085 On

I assume you're not using the 'JSSE-Java' stack (i.e. the real one that comes builtin to 'standard' Java) because AFAICT that always sends session-id in TLS1.2 or lower ServerHello.

If you're using OpenSSL, either directly by specifying an APR 'protocol' (in all versions I've seen) or using a NIO or NIO2 'protocol' with sslImplementationName selecting OpenSSL (in at least 8.5 up) or automatically with AprLifeCycleListener (in all versions I remember), then for TLS1.2 and lower:

  • if session tickets are enabled and the client requests one, OpenSSL server sends no session-id and does send a ticket (later in the handshake). You can disable this with SSLHostConfig.disableSessionTickets or Connector.SSLDisableSessionTickets (in at least 8.5 up, don't remember for earlier).

  • without ticket(s), OpenSSL server does send session-id unless session caching is disabled, which AFAICS there is no way to do in Tomcat, so effectively always.

Note however that TLS1.3 is very different, if and when your systems move up to it. As one of many sops to broken middleboxes, RFC8446 requires (and both JSSE-Java and OpenSSL correctly implement) that all ClientHello have a random session-id value and all ServerHello echo it, even when resumption is not being done (e.g. on the first connection for a given endpoint pair), but this does not actually identify any session and will not be the same for related connections for the same pair.

This is (at least mostly) because 1.3 no longer does resumption by saving and reusing the session master secret; now it supports forward secrecy by instead optionally setting one or several resumption secret(s) one-way-derived from the current connection secret, which is(are) established and identified by NewSessionTicket message(s), and subsequently referenced and used by Pre-Shared Key (PSK) mode. And 1.3 NewSessionTicket is encrypted, so a middlebox like a (nonterminating) loadbalancer won't be able to use it.