Re: [TLS] Questions about TLS Server Name Indication extension

[Martin Rex <[e-mail]>]

Nelson B Bolyard wrote:
> 
> On 2009-10-29 16:26 PDT, Martin Rex wrote:
> > Nelson B Bolyard wrote:
> >> There's another issue that arises with both the SNI extension and a single
> >> session ID space for the entire physical server.  Which takes precedence?

If the SNI made a difference in the server credential when the session
was originally created, then the SNI MUST make the same difference
for resume.  The a requirement for consistency and reproducable behaviour.

If the SNI did not make a difference when the cached session was
originally created (e.g. the server doesn't support SNI), then it
does not need to make a difference on resume.


> >>
> >> Consider this scenario:
> >> Physical host has two virtual hosts, A and B.
> >> First handshake:
> >>   client sends SNI with host name A, empty session ID.
> >>   server does full handshake, session ID 1.
> >> Second handshake (renegotiation):
> >>   client sends SNI with host name B and session ID 1,
> > 
> > That client is obviously broken.
> 
> Perhaps, but the question is what does the server do about it?

Compensate for the broken client and perform a full SSL handshake.

A broken client is no excuse for inconsistent or non-predictable
server behaviour.  Since most real server limit the size of their
session cache, you will, depending on the load of the server,
not be able to predict at what point the server will have purged
the cached session from his cache and will have to perform a
full TLS handshake.

If that full handshake will result in a TLS session with
substantially different characteristics, or even with a completely
different server credential, then the server behaviour will
effectively become inconsistent and non-predictable if
the server agrees to resume sessions that substantially differ
from other session characteristics specified in the ClientHello.

A server implementation that will behave inconsistent and
non-predictable is always a bad idea.  It does not matter that
the spec fails to discourage or prohibit such a behaviour.
It remains a pretty a bad idea and a sign of a broken server
even when the spec does something stupid like recommending
such inconsistent and non-predictable behaviour.


> 
> >> Session ID 1 implicitly identifies host A.
> >>
> >> The server could
> >> A)  Honor the session ID and ignore the SNI.
> >> B)  Compare the host name in the SNI with the host name for session ID 1,
> >>     observe the mismatch, and do a new FULL handshake for host B.
> >> C)  Compare the host name in the SNI with the host name for session ID 1,
> >>     observe the mismatch, and return a fatal error alert.
> > 
> > If the server supports virtual hosting through SNI, 
> 
> that's a given for this exercise
> 
> > it should look up the session ID of the client only in the session cache 
> > associated with the hostname A.
> 
> And it should choose hostname A because why?  Remember that in the above
> example, the SNI bears host name B.

Sorry for my mistake.  A session resume request with SNI B should
be looked up in the session cache associated with SNI B, of course.
(if the server supports SNI).


> 
> > If a TLS session resume proposal with [an] SNI for B arrives,
> > there will be no cached session with that session ID in the
> > TLS session cache tied to credential for A, so it must result
> > in a full TLS handshake.
> 
> So, you're proposing that the server should look in the SNI first to see
> which host name is there, and use that info to decide which virtual host's
> server session cache to examine for the numbered session?

Correct.


> In other words,
> each virtual host has its own separate session cache with fully overlapping
> spaces of session ID numbers, disambiguated by the SNI host name, yes?
> In this model, an SNI would be absolutely required to resume a session that
> had been established with an SNI, yes?

Correct.

 
> 
> > A server that has different credentials for A and B (and would
> > use them based on SNI 
> 
> The whole point of SNI is to have different credentials for different
> virtual hosts.  If you don't have different credentials for different
> virtual hosts, (e.g. if you have a single certificate for all your
> virtual hosts) then you don't need SNI.

If a server supports SNI, but shares a single credential for several
(or all) virtual hosts, then there would be no consistency or
non-predictability problem if the server shared the TLS session
caches in the same fashion.

In my architecture, the SSL session cache of the server is tied
to the server credential.

If the architecture permits updating the server credentials
while the server is running under full load, then you really want
to be able to flush exactly and efficiently the cached TLS sessions
related to that specific previous credential and leave the rest
of the cached TLS sessions assiciated with other, still unchanged
credentials, untouched.


-Martin