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

[Michael Gray <mickgray at au1.ibm.com>]

<nelson at bolyard.me> wrote:

> 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,
>
> 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.
>
> RFC 5246 seems to suggest choice A.  It says:
>
>    Most current TLS extensions are relevant only
>    when a session is initiated: when an older session is resumed, the
>    server does not process these extensions in Client Hello, and does
>    not include them in Server Hello.
>
> But I tend to lean towards choice B myself.
>
> What do other SNI server implementations do in this case?

A for IBM native SSL.  The Client SNI data is only processed if the session
can NOT be resumed.

Also as an answer to the previous question; we only consider that the
Client has sent a single name in Client SNI request.

Also on previous note <snip> 'because they don't want to send the client
cert over the wire in the clear" <snip>

For what reason would you require a client cert or a host name or a host
certificate to be not treated as public information?  Of course it could be
a good way to cover your tracks if you were up to no good :-)

Mick Gray
IBM

> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls