Re: [TLS] Multiple domain names in SNI (was Questions about TLS Server Name Indication extension)

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

Here's a possible reason for a client to include multiple domain
names in the SNI.  Suppose a user enters "foo.edu" into their
browser.  The browser may decide to send the two names "foo.edu"
and also "www.foo.edu" to the server in an attempt to connect on
the first try, rather than get rejected on the first connection
and have the overhead of retrying.

Even if you disagree that that is a possible scenario, if you want
to restrict what you can do with a protocol there should be a good
reason to do it.  Either it must present a security issue, or it
must cause undue burden on implementers for no benefit.  I don't
see how it is a security issue for the server to look up more than
one name, and there is no burden in adding a simple loop to look
up those names sequentially.  In fact, you already need the loop
to skip any name types you don't recognize, so the issue is whether
you put a break statement in your loop or not.

Mike



Nelson B Bolyard wrote:
> On 2009-10-28 17:04 PDT, Michael Gray wrote:
>> <[e-mail]> 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.
> 
> Thanks, Mick, for those concise answers.  Sadly, I don't sense that we
> have a consensus from among the responses yet, except on the point that
> the SNI client hello should only contain one name of each type.
> 
> I think that interoperability demands that we standardize these answers.
> 
> I predict that we'll end up with these below(which I think match yours)
> but I fear that existing implementations differ from these a fair bit.
> 
> - Only one name per type is allowed and used in the client hello SNI.
> 
> - The session ID space covers all the sessions for the entire physical host
> including all the virtual hosts, so by itself, the session ID contains all
> the information necessary to determine which virtual host uses the session
> with that ID.  It is not necessary to consult the SNI host name to know
> which virtual host's session cache to examine to find the session ID.
> 
> - The SNI extension is ignored if the session can be resumed based on the
> session ID, and no matching/checking is done to ensure that the SNI host
> name matches the name in the resumed session, when the session is resumed.
> 
>> 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?  
> 
> I don't know.  I work on NSS, an open source TLS library that is used in
> lots of applications and is discussed in an open mailing list and newsgroup
> (mozilla.dev.tech.crypto).  One of the application developers who uses NSS
> has this issue, but I don't know why.  I'd guess it's the usual extreme
> security p\a\r\a\n\o\i\a\ precautions that have kept me employed. :)
> 
>> Mick Gray
>> IBM