[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Extensions and session resumption
Mike wrote:
>
> My code wants at least the server name extension
> to be in the client hello in order for the server
> to easily find the cached session (since you can
> set up multiple session caches). But it also makes
> some sense to require the inclusion of truncated
> HMAC, for example.
The (always server-generated) SSL session ID is 32 Bytes,
so it is long enough to accomodate hints for the server
side SSL session cache management.
However, very few SSL stacks seem to take advantage of that.
The server could assign certain Bits/Bytes in the SSL session ID
for specific purposes, one possible _example_:
- 128 bits (16 Byte) to carry a cryptographic random nonce
(to make it difficult for attackers to guess SSL session IDs
- 64 bits to create a per-SSL-cache unique session identifer
(e.g. increasing counter value). Just make sure the
old sessions are expunged from the SSL session cache before
the 64-bit counterspace completes a full cycle.
- 64 bits in custom slicing to distinguish/recognize individual
servers of a server farm (or multiple virtual hosts or both)
When done this way, you no longer have to search the SSL session
cache for a collision when creating a new SSL session ID, and
rather than caclulating a hash value on the SSL session ID when
looking up in the session cache, you could use bits from your
session ID (e.g. from the strong random bits) directly, they
should have a pretty even distribution.
The _client_ can not do this optimization on his SSL session cache
since it must accept whatever session ID the server issues.
-Martin
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls