Re: [TLS] Multiple Session Caches and SNI (was Questions about TLS Server Name Indication extension)

[Michael D'Errico <[e-mail]>]

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.

Mike



Nelson B Bolyard wrote:
> On 2009-10-27 23:54 PDT, Peter Gutmann wrote:
>> Nelson B Bolyard <[e-mail]> writes:
>>
>>> I eagerly await your answers and comments.
>> OK, I'll bite:
>>
>>> Q1) A client hello's SNI extension is defined such that it may contain 
>>> multiple names.
>> Intuitively I would say option (a) is the right one, if you're expecting
>> to connect to a.foo.com then it doesn't seem to make much sense to say
>> you'd also like b.foo.com, c.foo.com, amazon.com, youtube.com, and
>> phishme.com.  I'm sure someone can dream up some bizarre corner case
>> where you could in theory possibly somehow maybe do this, but in the
>> interests of implementation sanity I'd say you're only allowed one name.
> 
> I've been informed that the SNI implementation in OpenSSL/mod_ssl/Apache
> only honors the first host name in the client hello SNI extension, and
> will send an unrecognized_name alert if that first name is unrecognized.
> 
> I'm quite willing to follow that example and let that become the de facto
> standard.  I just wish the RFC was clear about it, and wonder why the RFC
> even allows multiple names to be sent.
> 
>>> Q2) if multiple non-synonymous names are included, is the server free
>>> to pick any one that it wants?
>> This one is resolved by the solution for Q1 above.
>>
>>> Q3) Consider the "renegotiation" case, where a client and server
>>> negotiate an initial SSL handshake ("in the clear") and then negotiate
>>> a second handshake over the encrypted channel established by the first
>>> handshake.
>> I'd say it's not permitted, it's still the same server and (again) all
>> you're going to do is create confusion if you allow new SNI's to be
>> inserted at this point.  This answers all the subquestions in one.
> 
> Well, consider that there are people who don't want to do client
> authentication in the initial handshake because they don't want to send the
> client cert over the wire in the clear.  Perhaps they also don't want to
> send the virtual host name in the clear, or receive the cert for the
> intended virtual host in the clear. So, one could imagine that they do
> an initial handshake without any SNI, then a subsequent renegotiation
> with SNI.
> 
> I'm not advocating that.  I'm merely suggesting that forbidding SNI in
> renegotiation might be seen as unnecessarily restrictive in some applications.
> 
>> Q4 and 5 get a bit complicated, I'd need to hear a bit more about the 
>> circumstances where this might occur...
> 
> I received some other email that suggests that my use of the word "scope"
> rather than "space" may have made the question unclear, so let me try to
> reword Q4 here.
> 
> In the context of a physical server acting as multiple virtual server,
> is the space of session IDs coming from that server a single space that
> encompasses all the sessions for all the virtual servers served by that
> physical server?  Or does each virtual server have its own separate space?
> 
> If each virtual server has its own separate session ID space, then when
> attempting to "resume" or "restart" a TLS session, the client hello MUST
> bear an SNI extension to inform the physical server which virtual server's
> session ID space contains the given session ID, and each virtual server
> potentially has its own separate session store/cache.
> 
> OTOH, if there is a single session ID space for the entire physical server
> covering all the virtual servers, then each cached session must record and
> identify the virtual server with which it is associated.
> 
> I'm just wondering which way is the right way to implement session cache
> lookup in an SNI environment.