Re: [TLS] Server Name Indication (SNI) in an IPv6 world?

[Matt McCutchen <[e-mail]>]

On Tue, 2010-10-26 at 16:35 -0700, =JeffH wrote: 
> What do folks think, will the TLS SNI extension still be employed as much in 
> the IPv6 world as it is in the IPv4 world?
> 
> The question stems from the simple observation (on some folks' part) of the 
> IPv6 world ostensibly having multitudinous addresses available, hence instead 
> of virtual-hosting via one IPv4-addressed entity (and employing SNI in order to 
> properly have a cert per virtual host, rather than one cert with a mutitude of 
> subjectAltName:dNSNames), one can instead just multi-home such hosting entities 
> with an IPv6 addr per virtual host.

SNI has another potential application to provide TLS-level protection
against connection redirection to a server that has a certificate for
the requested host name but does not wish to actually serve it.

For example, the lists.fedoraproject.org web server has a certificate
valid for *.fedoraproject.org.  Presumably the fedoraproject.org admin
team trusts that server, but they still need to make sure it won't
unintentionally serve lists.fedoraproject.org content to a client that
wanted admin.fedoraproject.org if an attacker redirects the connection.
The server can reject connections with a server_name extension other
than lists.fedoraproject.org (note that the server_name is integrity
protected as part of the handshake).  Some application protocols have
similar mechanisms, such as the HTTP Host header, that can be checked as
a fallback.  Connections that don't specify the desired host name via
either SNI or an application-level mechanism will be vulnerable unless
the server is willing to refuse all such connections.

Incidentally, it looks like lists.fedoraproject.org does not check
either SNI or the HTTP Host header.  I made a connection and indicated
admin.fedoraproject.org in both places and it happily served me wrong
content.  I will file a ticket.

-- 
Matt