Re: [TLS] Multiple Session Caches and SNI (was Questions about TLS

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> The only thing you can count on when resuming a session is the session
> ID.  If you have more than one session cache, then you need to be able
> to determine solely from the session ID which session cache contains
> the session.  I do this by structuring the 32 bytes of the session ID
> into a 6-byte cache ID, a 10-byte counter, and 16 bytes of random noise.
> 
> The cache ID makes it easy to determine which cache to look in when
> trying to locate a session; the counter guarantees uniqueness of session
> IDs (the upper 5 bytes are initialized with the creation time); and the
> random component makes it unlikely for an attacker to guess a valid
> session ID randomly.
> 
> My implementation allows virtual hosts to have their own session cache
> or to share their cache with any number of other hosts.  Since session
> IDs are unique, the benefit to sharing is to share configuration
> parameters.  You can specify a limit to the total number of cached
> sessions and the expiration time on a per-cache basis.


It's perfectly sensible that TLS server composes the TLS session IDs
in a fashion that facilitates cache management and session lookup
(including guaranteed uniqueness when creating new session IDs,
obviating cache collision checks).

Keep in mind, that the security of the sessions do not come from
uniqueness and non-predictability of the session ID, however.
SSL session IDs travel in the clear in the client hello and
their purpose in life is to be re-used "replayed" frequently. :)


In addition to cache management aspects, the TLS server should keep
robustness in mind.  e.g. robustness against TLS clients with
a broken client-side TLS session cache management that will
recklessly propose a TLS session resume for a session (ID) originally
established with Mars to just about every earthling they're asked
to connect to later on.


And before a TLS server checks for existence of a TLS session,
whose session ID is proposed in a ClientHello, it should determine
wheter it would be willing to establish a new session through
a full handshake based on the other information in the ClientHello
and under what conditions it would do so.

If the TLS server finds a TLS session with the proposed session ID
in his cache, it should then use the results from the previous
determination of the ClientHello parameters whether it is OK to
attempt to resume the cached session, or whether it is advised
to perform a full SSL handshake, because of a significant mismatch
of the newly determine session characteristics from those
of the cachend session identified by the client-proposed Session ID.


This is a simple and straightforward robustness principle leading
to consistent behaviour, that will save implementors and consumers
of the technology a lot of time and headaches.


-Martin