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

From: =JeffH <[email-masked]>
Date: Tue, 26 Oct 2010 16:35:50 -0700

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.

thoughts?

=JeffH

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2010 01:53:08 +0200

=JeffH <[email-masked]> writes:

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

It will be relevant for sites using CNAME redirection for example.
Sadly the IPv4 address situation has made it common for people to pay
for IP addresses, so I suspect people will use SNI to avoid excessive
charges for IPv6 address like they do today.  (I get 20 IPv6 addresses
for the price of one IPv4 address at one VPS hosting provider I'm
using.)

/Simon

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Oct 2010 22:16:20 -0400

> 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

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Oct 2010 22:49:04 -0400

> content.  I will file a ticket.

The ticket, in case anyone is curious:

https://fedorahosted.org/fedora-infrastructure/ticket/2455

Has this kind of issue been discussed before?  I wonder if many other
sites are affected.

-- 
Matt

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 27 Oct 2010 10:17:04 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt
> McCutchen
> Sent: Tuesday, October 26, 2010 7:49 PM
> To: IETF TLS WG
> Subject: Re: [TLS] Server Name Indication (SNI) in an IPv6 world?
> 
> Has this kind of issue been discussed before?  I wonder if many other sites
> are affected.

On non-SSL hosts this gets a lot of play as web servers that don't pay attention to Host headers can become victims of DNS rebinding attacks.  So, only serving content you really intend to for given hostnames is a pretty good idea.

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Wed, 27 Oct 2010 12:19:07 -0500

On 10/27/2010 11:17 AM, Steingruebl, Andy wrote:
>
> On non-SSL hosts this gets a lot of play as web servers that don't
> pay attention to Host headers can become victims of DNS rebinding
> attacks.

What?! If clients are willing to make non-SSL connections and are also 
subject to DNS rebinding, then Host headers are the least of your problems.

> So, only serving content you really intend to for given
> hostnames is a pretty good idea.

(This is not in response to what Andy said, it's just a general 
observation.)

People sometimes accuse me of having a black-and-white view of security, 
but it just seems irresponsible to me to even discuss relative levels of 
insecurity when the whole configuration looks 100% owned.

- Marsh

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 27 Oct 2010 11:22:44 -0600

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marsh Ray
> >
> > On non-SSL hosts this gets a lot of play as web servers that don't pay
> > attention to Host headers can become victims of DNS rebinding attacks.
> 
> What?! If clients are willing to make non-SSL connections and are also subject
> to DNS rebinding, then Host headers are the least of your problems.

Sorry, my point is that preventing DNS rebinding relies on client security in many ways, but to make it happen a server also has to serve content for hostnames it doesn't really serve content for.  With TLS this is hard(er) to make happen because of certificate warnings.  For non-TLS, there aren't any indicators.  Servers should be configured to only serve data for their hostnames.  Or, so I'd argue.

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Wed, 27 Oct 2010 15:48:24 -0500

On 10/27/2010 12:22 PM, Steingruebl, Andy wrote:
>> What?! If clients are willing to make non-SSL connections and are
>> also subject to DNS rebinding, then Host headers are the least of
>> your problems.
>
> Sorry, my point is that preventing DNS rebinding relies on client
> security in many ways, but to make it happen a server also has to
> serve content for hostnames it doesn't really serve content for.
> With TLS this is hard(er) to make happen because of certificate
> warnings.  For non-TLS, there aren't any indicators.  Servers should
> be configured to only serve data for their hostnames.  Or, so I'd
> argue.

Ah that makes sense, I was not fully getting your meaning.

Still, who's to say that the thing that gets the incoming connection at 
the re-bound DNS name will necessarily even be an HTTP server? I know 
browsers are increasingly blacklisting known ports, to try to mitigate 
this sort of thing.

It could be mildly discomforting to see an invalid host header printed 
on the address label of an item returned by the postal service after 
installing that high-speed check printer/stuffer/mailer!

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 27 Oct 2010 15:09:20 -0700

> The question stems from the simple observation (on some folks' part) of 
> the IPv6 world ostensibly having multitudinous addresses available, 
> 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.
> 
> thoughts?

Sending the host name through the SNI gives the application one more
piece of data it can use in its security decisions.  Rather than
implicitly believing "whatever connections we receive on this socket
are for www.example.com," the application can check whether the client
really thought it was trying to reach that host.

I feel that this is independent of IPv4 vs. IPv6.

Mike

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 28 Oct 2010 00:01:28 -0400

On Tue, 2010-10-26 at 22:49 -0400, Matt McCutchen wrote:
> Has this kind of issue been discussed before?

The question remains open.  But I will call it a connection diversion
attack.

> I wonder if many other sites are affected.

I looked through my browser history for registered domains containing a
TLS web server bearing a wildcard certificate and another subdomain on a
different IP address.  In almost all cases, the server was willing to
send me wrong content when I asked for the other subdomain via SNI and
HTTP Host.  Strictly speaking, this is a vulnerability.  Usually the
effect is just goofy, though on one major web site which I won't name,
it led to XSS.

How can I get the message out to holders of wildcard certificates that
they should prevent this attack?

-- 
Matt

---

From: Steven Bellovin <[email-masked]>
Date: Thu, 28 Oct 2010 09:17:59 +0200

On Oct 27, 2010, at 1:35 50AM, =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.
> 
> thoughts?
> 
I suspect that a lot of sites running dual stack will do this, just to ease configuration changes.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Marsh Ray <[email-masked]>
Date: Fri, 29 Oct 2010 10:08:27 -0500

On 10/27/2010 11:01 PM, Matt McCutchen wrote:
> Strictly speaking, this is a vulnerability.  Usually the

I've always been suspicious of wildcard certs, but didn't have real 
ammunition to argue against them. You may have identified one, but 
people may point out that it's only an issue in combination with the 
known problem of HTTP servers accepting invalid Host headers.

Here's what I would do:

* Contact the three or four groups doing net-wide SSL cert surveys (SSL 
Observatory, Qualys, etc). Get statistics from them and convince them 
that wildcard certs are a vulnerability worth flagging.

* Find existing CVE number(s) which involve this vulnerability 
specifically or wildcard certs general. Referencing a CVE immediately 
sets many processes in motion for organizations to take it seriously.

* Post a description of the vulnerability to the [Full-Disclosure] 
mailing list. Be prepared for no intelligent discussion to ensue, but 
you can be sure that it will be read by the people who matter. It's 
likely that bad guys and professional pen testers will say "well duh 
everybody knows that already" yet there will also be a lot of site 
admins shocked to find they are vulnerable.

* Publish an open-source point-and-click exploit tool, either as a 
standalone module or part of an existing framework (e.g. Metasploit). 
This is not bad-guy hacking (the bad guys know about this already), it's 
simply the process that the industry has chosen, and it definitively 
settles the "is this or is it not a real vulnerability" question.

A plethora of examples show that the availability of a public exploit 
usually greatly reduces the area under the vulnerable-systems-over-time 
curve.

For example, every network app developer knows that plaintext HTTP and 
open WiFi provides absolutely no security, yet the publicity around
http://www.google.com/search?q=firesheep
will probably do more for the adoption of TLS than anything else this year.

- Marsh

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 29 Oct 2010 11:54:58 -0400

Marsh, thanks for the detailed advice.  Here are responses to some of
your points:

> known problem of HTTP servers accepting invalid Host headers.

I don't consider this issue a reason not to use wildcard certificates.
Since name-constrained delegation is (unfortunately) not widely
implemented by clients and not available for a reasonable price from
public CAs, wildcard certificates are quite practical for organizations
that want to operate a large number of subdomains.  But like any
security technology, they require careful deployment to prevent bad
things from happening.

> that wildcard certs are a vulnerability worth flagging.

As above, I won't argue that, but maybe they could incorporate the same
test I did manually, of connecting to a server with a wildcard
certificate and sending a request with SNI + HTTP Host for a subdomain
supposed to be served elsewhere.  Qualys/SSL Labs is probably the right
group to do this since they already look for different kinds of
deployment mistakes, while SSL Observatory is more focused on studying
the sprawl of the public CA system.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Oct 2010 21:27:14 +0200 (MEST)

> known problem of HTTP servers accepting invalid Host headers.

This is NOT an attack on TLS or TLS server certs.  And the assumption
that the use of TLS would prevent a behaviour that exists just the
same for this server on port 80 is naive.

Virtual hosting of Web Servers is a convenience function,
and whether and how much seperation of content actually exists
is completely at the discretion of the server.

The use of TLS provides a protected communication channel between
two endpoints.  It does not add anything to the trustworthyness
of the communication within.  Any server features visible on port 80
will likely be available in just the same fashion on port 443.

The Garbage-in, garbage-out principle is not affected by replacing
the garbage truck with an armoured car with security guards while
still delivering the very same contents of the very same garbage bins.

-Martin

---

From: Dean Anderson <[email-masked]>
Date: Mon, 1 Nov 2010 00:44:57 -0400 (EDT)

Hi Jeff,

Until IPV6 is a viable platform independent of IPV4, it's probably
premature to consider how one might use it with TLS because it's not
stable in its present form.  At present and for the forseeble future,
IPV6 doesn't work independently from IPV4, and as-is, isn't a viable
platform.  Some people might think that is a controversial statement,
but those people been denying the obvious since at least the failure of
the great deployment effort of 2003. And probably even before that since
the 2003 effort was forseeably unrealistic in the 2002 planning stages.  
Present plans are to repeat what didn't work in 2003, with no
substantial change.

I think the easiest way to understand the basis for saying IPV6 is dead
is this:  Anyone who publishes an AAAA record is immediately penalized
by the blackholing of traffic as IPV6 connections are attempted over
IPV4 interfaces. The root cause of this is that DNS doesn't have the
necessary separate stacks;  consequently, there is no such thing as an
IPV6 DNS stack. So there is just one DNS stack, and as soon as anyone
tries to use IPV6, they have to use an AAAA record in the IPV4 DNS, and
as soon as they do that, they get blackholed. Foot, gun, bang. Rollback
on IPV6. End of story. That's why now when you google IPV6, you bring up
more and more pages on how to disable it. And so, it's dead.

DNS bungling is not the only reason it's dead, of course. Just like
there's no single cause for the roman empire collapse. But in the same
way that many people think it was the barbarians who caused the roman
collapse, I think it was DNS bungling that caused IPV6 to fail. But
there are actually a whole lot of reasons. But this isn't the place to
post-mortem IPV6.

		--Dean

On Tue, 26 Oct 2010, =JeffH wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494