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

[Martin Rex <[e-mail]>]

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?
> 
> 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.

> 
> 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, it should
look up the session ID of the client only in the session cache
associated with the hostname A.

If a TLS session resume proposal with and 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.

A server that has different credentials for A and B (and would
use them based on SNI is definitely broken if it agrees to a
proposed resume of a session originally established with A
in a ClientHello that carries an SNI for B, because the server
knows exactly that the server certificate that the client
has for this session is NOT the same certificate that the server
would send in a full handshake for B.  And similiar uncertainty
may apply to availability of a client certificate of even
an already cached client certificate.
 

-Martin