Subject: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 7 Nov 2013 16:32:50 +0000

Hi,

Thank you for the helpful TLS WG meeting yesterday at
the IETF88 and to the WG for the excellent work on
TLS.

No consensus was reached on ‘Reduced RT handshake with
privacy”.

Some thoughts why SNI (host name) and ALPN should be
transmitted encrypted and not in clear.

1. Meta-data is important. Meta-data tells a lot about a person.
Meta-data can get a user killed or worse. Transmitting the host-name
(meta-data) in clear in TLS is not good (as in ‘not good because it
can get you killed’ and there is no alternative for the user – unless
the user is a tech-wizard.).

2. What is the message to the user? TLS is secure – well, kind’a.
TLS secures some things but that you read freedom4gays.com,
secure.washingtonpost.com or myfavoritepoliticalparty.com is
leaked – but we still call it secure???

3. Governments just love filtering by site. (Block secure.twitter.com
but not blub.com). Same goes for filtering by application (ALPN).
Transmitting this information in clear plays into the hands of the
adversary.

There are other ways how an adversary can extract the same meta-data.
This should not deter us from fixing it in TLS. Maybe we will find a
solution for the other problems as well (like confidential DNS).

Fixing this in TLS increases the cost of surveillance. This is the goal.

An adversary can no longer use passive surveillance to extract SNI/ALPN.
The adversary is forced to do detectable active surveillance to get the
meta-data).

Those who give up security for a little bit of performance neither
deserve security nor performance.

Regards,

Ralf

---

From: Watson Ladd <[email-masked]>
Date: Thu, 7 Nov 2013 08:39:53 -0800

> the user is a tech-wizard.).
They can use Tor. They need to anyway: reverse DNS lookups are not
rocket science.
> leaked – but we still call it secure???
This is as secure as sending a sealed envelope through the mail.
> solution for the other problems as well (like confidential DNS).
No, the other problem is you connect to the server and ask it to show
you a page,
and learn what the server is. The sole exception is multihosting,
which is getting
less common for various reasons.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 7 Nov 2013 17:03:01 +0000

> They can use Tor. They need to anyway: reverse DNS lookups are not

[...]

> less common for various reasons.

As a hacker I would love TLS to leak the host information. It would enable
me
to find out which user connects to admin.blubb.com and who connects just to
www.blubb.com (both domains hosted on same server).

Your comments are wrong in this scenario: Connecting to the server does not
help
the hacker to gain above information. Neither does reverse lookup.

TLS leaks it and there is no other way the hacker would get this
information if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the
problem.

regards,

ralf

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 17:30:11 +0000

Hi, Ralf.

I'm not disagreeing with you regarding 1.3. At least in the long version of the handshake (which you should be able to enable in any browser, if you want a little more privacy in exchange for an extra roundtrip).

But ordinarily, the sites that can get you killed are not collocated with benign sites. And even when sites are collocated, the servers demux not based on the SNI parameter in the TLS handshake, but based on the Server header in HTTP. The only use of the SNI parameter is for selecting the right certificate. So if you try to go to https://www.gmail.com , you get a certificate for www.gmail.com<http://www.gmail.com> , before being redirected to the same server, but this time with the URI https://mail.google.com .

It would be much nicer if we could update HTTPS (RFC 2818) to support this kind of multi-homing so as to make SNI superfluous. For example, if the server certificate could list the different domain names that it was valid for. Yes, I know there's an economic side to this as well. I'm sure the CAs could charge by alternate name if needed.

Yoav

On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:

[...]

As a hacker I would love TLS to leak the host information. It would enable me
to find out which user connects to admin.blubb.com<http://admin.blubb.com/> and who connects just to
www.blubb.com<http://www.blubb.com/> (both domains hosted on same server).

Your comments are wrong in this scenario: Connecting to the server does not help
the hacker to gain above information. Neither does reverse lookup.

TLS leaks it and there is no other way the hacker would get this information if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the problem.

regards,

ralf

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Nov 2013 12:39:07 -0500

Ø  For example, if the server certificate could list the different domain names that it was valid for.

Like subjectAltName?  But unlike SNI, that requires the hosted parties to cooperate in getting the certificate. SNI does not.

                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 7 Nov 2013 09:47:51 -0800

I don’t think the economic issues should be a consideration here, just
whats the right solution.

CAs are already required to include all the domain names in the SAN (
https://www.cabforum.org/Baseline_Requirements_V1.pdf) and all CAs have
models for doing this.

The core issue is that SNI doesn’t require shared keys across parties or
cooperation of any type, using multi-san certificates does. This works in
some cases, for example when the arbitrator (like a CDN) manages that
cooperation but in some cases its not possible for them to.

In such cases they need a dedicated IP or SNI.

Ryan

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Yoav
Nir
*Sent:* Thursday, November 7, 2013 9:30 AM
*To:* Ralf Skyper Kaiser
*Cc:* [email-masked]
*Subject:* Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS
1.3

Hi, Ralf.

I'm not disagreeing with you regarding 1.3. At least in the long version of
the handshake (which you should be able to enable in any browser, if you
want a little more privacy in exchange for an extra roundtrip).

But ordinarily, the sites that can get you killed are not collocated with
benign sites. And even when sites are collocated, the servers demux not
based on the SNI parameter in the TLS handshake, but based on the Server
header in HTTP. The only use of the SNI parameter is for selecting the
right certificate. So if you try to go to https://www.gmail.com , you get a
certificate for www.gmail.com , before being redirected to the same server,
but this time with the URI https://mail.google.com .

It would be much nicer if we could update HTTPS (RFC 2818) to support this
kind of multi-homing so as to make SNI superfluous. For example, if the
server certificate could list the different domain names that it was valid
for. Yes, I know there's an economic side to this as well. I'm sure the CAs
could charge by alternate name if needed.

Yoav

On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser <[email-masked]> wrote:

[...]

regards,

ralf

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 Nov 2013 19:59:57 +0100 (CET)

Ralf Skyper Kaiser wrote:
> 
> Some thoughts why SNI (host name) should be

But you are aware that there is no such thing as a
"confidential DNS lookup" (confidential towards whom anyways),
so that in general, what your browser is connecting will be
directly preceded by a cleartext DNS lookup with that very name...

(Not revealing the "next protocol" or client certs/identities
 is a different issue.)

-Martin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 07 Nov 2013 14:07:51 -0500

> directly preceded by a cleartext DNS lookup with that very name...

Sure, but that is a bug in DNS, not a bug in TLS, and there are 
proposals (however farfetched) to work around that, like DNSCurve [0]. 
But fixing DNS leakage is out-of-scope for this working group.

Fixing TLS is in-scope, though, and TLS shouldn't leak information just 
because other related protocols also leak information.

Putting SNI info in an encrypted handshake would make that information 
unavailable to passive attackers.  Despite still being vulnerable to 
active attackers (possibly at the cost of a connection failure) this is 
a win, and if we can offer this protection in the protocol, we should.

	--dkg

[0] http://dnscurve.org/

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 7 Nov 2013 19:36:17 +0000

Hi Martin,

(see also my full email further below where I mention DNS and why the
shortfall of current DNS should not stop us from fixing TLS - because
otherwise the DNS guys say there is no need to fix DNS because SNI in TLS
is cleartext as well...we have to start somewhere.......Please also see
comment on how just having DNS leaking this information raises the cost for
surveillance and in some cases makes it impractical if not impossible -
that's the goal.)

regards,

ralf

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 19:46:42 +0000

IMO, if both sites are either collocated on the same machine, or hosted behind the same SSL accelerator, they already share enough that multi-SAN is not a bad thing.

With SNI is it currently stands, the site you are looking for is sent in the clear. If we keep the choose-certificate functionality in 1.3, we still leave it exposed in either the SNI or in the certificate that the server sends. A generic certificate is the only one that hides what the client is browsing.

On Nov 7, 2013, at 9:47 AM, Ryan Hurst <[email-masked]<mailto:[email-masked]>> wrote:

I don’t think the economic issues should be a consideration here, just whats the right solution.

CAs are already required to include all the domain names in the SAN (https://www.cabforum.org/Baseline_Requirements_V1.pdf) and all CAs have models for doing this.

The core issue is that SNI doesn’t require shared keys across parties or cooperation of any type, using multi-san certificates does. This works in some cases, for example when the arbitrator (like a CDN) manages that cooperation but in some cases its not possible for them to.

Ryan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yoav Nir
Sent: Thursday, November 7, 2013 9:30 AM
To: Ralf Skyper Kaiser
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

Hi, Ralf.

But ordinarily, the sites that can get you killed are not collocated with benign sites. And even when sites are collocated, the servers demux not based on the SNI parameter in the TLS handshake, but based on the Server header in HTTP. The only use of the SNI parameter is for selecting the right certificate. So if you try to go tohttps://www.gmail.com , you get a certificate for www.gmail.com<http://www.gmail.com> , before being redirected to the same server, but this time with the URI https://mail.google.com .

Yoav

[...]

regards,

ralf

Email secured by Check Point

<smime.p7s>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 19:48:58 +0000

On Nov 7, 2013, at 9:39 AM, "Salz, Rich" <[email-masked]<mailto:[email-masked]>> wrote:

>  For example, if the server certificate could list the different domain names that it was valid for.

Yes, but at the cost that the domain name is exposed in the clear. Both in the SNI and in the certificate.

Yoav

---

From: Seth David Schoen <[email-masked]>
Date: Thu, 7 Nov 2013 11:54:46 -0800

Daniel Kahn Gillmor writes:

> proposals (however farfetched) to work around that, like DNSCurve
> [0]. But fixing DNS leakage is out-of-scope for this working group.
> 
> Fixing TLS is in-scope, though, and TLS shouldn't leak information
> just because other related protocols also leak information.

And there might actually be some passive attackers who are on-path
with respect to the TLS session and not with respect to the DNS lookup
(for example, the DNS query might have been satisified by a recursive
resolver that's closer to the client than the eavesdropper is).

With CDNs, you sometimes get some pretty strange bedfellows on a single
server IP address, so the marginal information leak from SNI could be
pretty high!

-- 
Seth Schoen  <[email-masked]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 7 Nov 2013 19:54:57 +0000

Hi,

On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <[email-masked]> wrote:

>  IMO, if both sites are either collocated on the same machine, or hosted
> behind the same SSL accelerator, they already share enough that multi-SAN
> is not a bad thing.
>
>  With SNI is it currently stands, the site you are looking for is sent in
> the clear. If we keep the choose-certificate functionality in 1.3, we still
> leave it exposed in either the SNI or in the certificate that the server
> sends. A generic certificate is the only one that hides what the client is
> browsing.
> TLS mailing list
>

No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy' as
presented by Eric yesterday. Key Exchange is done before SNI is send and
auth is done as last. (What's now cleartext would then require
detectable-active attack).

regards,

ralf

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Nov 2013 14:55:47 -0500

> IMO, if both sites are either collocated on the same machine, or hosted behind the same SSL accelerator, they already share enough that multi-SAN is not a bad thing.

Our experience disagrees.

> With SNI is it currently stands, the site you are looking for is sent in the clear. If we keep the choose-certificate functionality in 1.3, we still leave it exposed in either the SNI or in the cer…

First, a disclaimer that this isn't a use-case my employer cares about much; on a personal note, I want more privacy.  But I don't see how you can make a 'generic certificate' that really meets the desired goal.  You already can't make a wildcard SAN for "*.com" or "*.co.uk" for example.

	/r$

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 20:06:44 +0000

On Nov 7, 2013, at 11:54 AM, Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi,

On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
IMO, if both sites are either collocated on the same machine, or hosted behind the same SSL accelerator, they already share enough that multi-SAN is not a bad thing.

No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy' as presented by Eric yesterday. Key Exchange is done before SNI is send and auth is done as last. (What's now cleartext would then require detectable-active attack).

You mean the one in 5.1.1.2 ?

Yes, but the client still sends the SNI before receiving the certificate. This makes it still visible to an active attacker.  But you are right that a passive eavesdropper is now precluded.

Yoav

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 Nov 2013 21:08:15 +0100 (CET)

> detectable-active attack).

I'm sorry, but I firmly believe this will be pure and useless obscurity
coming at a high cost.

The amount of "activity" for the attack is minuscule (just tear down
the connection when you see the TLSv1.3 client hello -- the client
*WILL* reconnect with SNI in the clear.  For the NSA, this is trivial,
they're actively doing stuff like this on a regular basis (Foxacid).

There are already lots of sites and lots of middle-boxes that cause
errors like this in a non-malicious fashion, that "detecting" such
an error is only going to annoy users, but not provide any benefit.

For those negligible situation where there might be any theoretical
benefit at all, it would be possible to define a seperate TLS extension
with the properties you're looking for, rather than messing up SNI.

-Martin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 7 Nov 2013 21:39:24 +0000

Hi,

For TLS 1.3 there can be a solution that the SNI is never send in clear.

The downgrade attack to TLS 1.2 is possible and would trigger the SNI to be
send in clear again.
(It requires an active attack).

We need the backward compatibility (from TLS 1.3 to TLS 1.2) for the
foreseeable future. That does not
mean that we should continue with the same flaws in 1.3 that we have in
previous TLS versions.

regards,

ralf

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 07 Nov 2013 15:17:41 -0800

> a win, and if we can offer this protection in the protocol, we should.

SNI is not limited to host names, though currently those are the only
defined names:

           enum {
               host_name(0), (255)
           } NameType;

If there is a need for a more opaque server identity, it could be defined
here.

Mike

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 07 Nov 2013 18:25:17 +0000

Yoav Nir:
> Hi, Ralf.
> 
> I'm not disagreeing with you regarding 1.3. At least in the long
> version of the handshake (which you should be able to enable in any
> browser, if you want a little more privacy in exchange for an extra
> roundtrip).
> 
> But ordinarily, the sites that can get you killed are not collocated
> with benign sites. 

I disagree. Cloud computing is a good counter example. AppSpot is the
perfect example where there are more benign sites than dangerous sites
and it is easy to use it for interesting tricks.

> And even when sites are collocated, the servers
> demux not based on the SNI parameter in the TLS handshake, but based
> on the Server header in HTTP. The only use of the SNI parameter is
> for selecting the right certificate. So if you try to go to
> https://www.gmail.com , you get a certificate for
> www.gmail.com<http://www.gmail.com> , before being redirected to the
> same server, but this time with the URI https://mail.google.com .
> 

The DPI boxes demux on whatever they can steal off of the wire.

> It would be much nicer if we could update HTTPS (RFC 2818) to support
> this kind of multi-homing so as to make SNI superfluous. For example,
> if the server certificate could list the different domain names that
> it was valid for. Yes, I know there's an economic side to this as
> well. I'm sure the CAs could charge by alternate name if needed.

I agree that RFC 2818 should be updated to reflect these kinds of uses.

All the best,
Jacob

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 06:02:32 +0100 (CET)

Daniel Kahn Gillmor wrote:
> Martin Rex wrote:

No need to develop and deploy anthing.
Just switch on IPsec (which allegedly is, according to the IPv6 fanciers,
already deployed everywhere).  This could adequately protect not only
DNS lookups, but also the entire cleartext phase of TLSv1.0/1/2 handshakes.
 
> because other related protocols also leak information.

Don't fix it if it ain't broken.
SNI was specifically DESIGNED to convey the server name in the clear.

Security only works in a meaningful fashion if you can ensure "hygiene",
otherwise it will be expensive obscurity and result in casualties.

> unavailable to passive attackers.

This is a dangerious illusion.  As long as SNI will travel in the clear in
protocol versions up to TLSv1.2, it *WILL* leak.  Maybe not from your
client, but someone elses older client going to the same service.

TLSv1.2 (rfc5246) was published in 2008, and its adoption rate is
about as bad as that of IPv6.  The more changes there are proposed
for TLSv1.3, the worse it will fail in the installed base.
TLSv1.2 already is a proven failure and the weakest TLS version
in existence.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 7 Nov 2013 22:34:15 -0800

> (It requires an active attack).
Why wasn't this fixed years ago? The client should indicate the
highest offered version when falling back, and the server should
signal if there is a problem. This was an issue with SSL 3.0 and TLS
1.0. It's still an issue today because SSL 3.0 is still out there.

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 13:31:48 +0100 (CET)

Yoav Nir wrote:
> the clear. If we keep the choose-certificate functionality in 1.3, we
> still leave it exposed in either the SNI or in the certificate that the
> server sends. A generic certificate is the only one that hides what the
> client is browsing.

Unless you go down the Tor path in its entirety, the site you're
accessing will be fairly close to always trivially distinguishable
by simple traffic analysis (sizes,amount and frequency of requests).

Next protocol will regularly suffer from the very same problem,
characteristic/distinct traffic patterns.

-Martin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Fri, 8 Nov 2013 15:28:46 +0000

Hi

> otherwise it will be expensive obscurity and result in casualties.

SNI was NOT DESIGNED to be convey the server name in clear. SNI was
designed so that the server can pick the right certificate.

SNI can be transmitted encrypted and should be transmitted encrypted (see
recent plenary sessions at IETF88).

> client, but someone elses older client going to the same service.

Martin, with your argument why should we fix anything at all in any product
or design?

The proposed solution FIXES passive pervasive surveillance in TLS 1.3.

Your proposal fixes nothing, keeps an identified and acknowledged security
flaw in TLS 1.3 and enables passive pervasive surveillance.

Let's make pervasive passive surveillance harder.

Your other concerns that there other ways how an attacker can get the host
name are noted and are out-of-scope for the TLS-WG (yes, the NSA can even
get a FISA order...but we wont fix that one either....and enabling IPSEC
does not scale (yet)).

regards,

ralf

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 08 Nov 2013 11:39:48 -0800

Ralf Skyper Kaiser wrote:
> transmitted encrypted and not in clear....

I'm fine with encrypting these as long as the server
receives them prior to selecting a certificate.

SNI allows for multi-homing (different server names
on the same IP), and ALPN allows you to put multiple
services on the same port (e.g. SMTP/POP3/IMAP all on
port 443 along with HTTPS/SPDY).  Each service might
require its own certificate.

Mike

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Fri, 8 Nov 2013 21:42:04 +0000

Hi,

absolutely. Encrypted SNI in TLS 1.3 will be received by server prior to
selecting a certificate.

ALPN could be encrypted as well (same reason, same solution).

regards,

ralf

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Nov 2013 01:55:46 +0100 (CET)

> designed so that the server can pick the right certificate.

SNI was DESIGNED to be in the clear.  In our server implementation,
I have implemented the server-side of SNI only at the application
level, not in the TLS protocol stack, i.e. I select the credential
that is used to perform the TLS handshake _before_ I start the
handshake.

> recent plenary sessions at IETF88).

What you seem to want to do is not SNI, but something else.

> Martin, with your argument why should we fix anything at all in any product

Don't fix it if it ain't broken.  SNI is not broken.

> The proposed solution FIXES passive pervasive surveillance in TLS 1.3.

This is going to be a waste of energy that is only making things
more complex, but neither better nor more secure.

> Let's make pervasive passive surveillance harder.

To me, this is self-illusion.  Why should NSA look at SNI at all?
They're collecting meta-data based on information that is always present
and necessary for the communication to succeed at all.  There are still
lots of clients around which do not send SNI.  And you could send crap
in SNI to servers that don't implement or use SNI, but I strongly doubt
that you would confuse XKeyScore by doing this.

-Martin

---

From: Sean Leonard <[email-masked]>
Date: Mon, 11 Nov 2013 18:34:36 -0800

> To me, this is self-illusion.  Why should NSA look at SNI at all?

Okay so here's the thing. A passive observer of the network can probably 
figure out that a particular TLS connection is intended for a particular 
hostname.

The client and server IP addresses are in the clear. No question.

To figure out the server's IP address from its hostname, the client must 
do a DNS lookup. This will be in the clear. Even if a particular client 
doesn't go over the (surveiled) public Internet to do the DNS lookup 
(due to local DNS server caching), for any nontrivial amount of 
connections, the DNS record will float through the public Internet in 
the clear at some point.

Thus an eavesdropper can easily correlate the reverse lookup, IP address 
-> hostname(s), in a minimal amount of time.

So, the fact that SNI is in the clear, is not really leaking additional 
information that a passive (but consistent and pervasive) eavesdropper 
would have figured out in the first place.

Unless of course you are using SNI to stuff in side-channel information 
(i.e., something other than a hostname)...but then you are not obeying 
the SNI protocol in the first place.

FWIW, I would prefer that all metadata (whether SNI or otherwise) not be 
in the clear. But as Martin Rex said, it being in the clear is not fatal 
to security.

-Sean

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 12 Nov 2013 10:06:27 +0000

Hi,

Martin, you are right that SNI is currently implemented and transmitted in
clear.
This was however not the primary design goal but rather a choice of
convenience
and lack of better/easier ideas. The primary design goal for SNI was to
allow
multi-homing HTTPS servers on the same IP (so that apache can select the
correct x509 certificate for whatever site the client requested). There is
no
practical or security benefit  or transmitting SNI in clear.

Sean, your argument "but DNS leaks infos as well, and the attacker can do
reverse
lookups, ..." etc are valid but shall not prevent us from fixing these
problems one by
one. DNS will support confidentiality. Reverse lookups do not work on
multi-homed
SSL servers [you only get 1 host name back but not 1,000 domains hosted on
that
host], .. etc etc).

I hear you loud and clear that a more work on other protocols (including
DNS) has to
done to prevent leaking of domain names. I agree.

Let's start with TLS and SNI.

regards,

ralf

On Tue, Nov 12, 2013 at 2:34 AM, Sean Leonard <[email-masked]> wrote:

> doesn't go over the (surveiled) public Internet to do the DNS lookup (due
> to local DNS server caching), for any nontrivial amount of connections, the
> DNS record will float through the public Internet in the clear at some
> point.
>
> (i.e., something other than a hostname)...but then you are not obeying the
> SNI protocol in the first place.
>
> in the clear. But as Martin Rex said, it being in the clear is not fatal to
> security.
>
> -Sean
>
>
>

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 12 Nov 2013 12:05:32 +0200

> On 12.11.2013, at 2.55, [email-masked] (Martin Rex) wrote:
> 

At this point I must point out that not everything is about NSA. There are certain countries that block DNS to the open internet and therefore all DNS queries are performed inside national borders. Some of these countries have also managed to block Tor with rather complicated active probing and IP blocks.

I can confirm that a working solution to easily get to services like google/facebook without full VPN is to edit /etc/hosts to point to some unblocked IP e.g. in Europe and use HTTPS. What makes me sad is the knowledge that SNI is leaking the hostname and makes those connections trivial to block, even though I haven't come across SNI based blocking yet.

I haven't put enough thought into this to say if encrypting SNI is technically feasible or adds too much complication. But I would like to hear how come in the situation I have just described (and have personally experienced) leaking SNI is not a problem? AFAIK these countries only do passive surveillance, because active surveillance would be too expensive and slow down connections too much.

Juho

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Nov 2013 10:17:48 +0000

On Nov 12, 2013, at 12:06 PM, Ralf Skyper Kaiser <[email-masked]>
 wrote:

> Hi,
> 
> Martin, you are right that SNI is currently implemented and transmitted in clear.
> This was however not the primary design goal but rather a choice of convenience
> and lack of better/easier ideas. The primary design goal for SNI was to allow
> correct x509 certificate for whatever site the client requested). There is no

There is a design I've seen at a site some years ago. I don't know how popular this is, but at least there's a non-empty set of servers doing this.

They have multiple servers within the datacenter and a reverse proxy. All server names resolve to the address of the reverse proxy. For each connection, it reads the ClientHello and extracts the SNI, and then forwards the ClientHello (and the rest of the connection) to the appropriate server. In no SNI, there is a default server (which is where most of the traffic is going anyways)

With encrypted SNI it would have to actually terminate the TLS rather than just look at the ClientHello.

Yoav

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 12 Nov 2013 11:11:10 +0000

Hi Yoav,

thanks for pointing this out. How widely is this technique used? (and
clients which do not support SNI [there are plenty!]
can not connect at all via HTTPS with what they are doing - odd. but i'm
not here to judge :>).

We shall not compromise the security of the many to accommodate the
performance needs of the few.

Get a F5 or equivalent SSL Proxy. Done.

regards,

ralf

On Tue, Nov 12, 2013 at 10:17 AM, Yoav Nir <[email-masked]> wrote:

> There is a design I've seen at a site some years ago. I don't know how
> popular this is, but at least there's a non-empty set of servers doing this.
>
> They have multiple servers within the datacenter and a reverse proxy. All
> server names resolve to the address of the reverse proxy. For each
> connection, it reads the ClientHello and extracts the SNI, and then
> forwards the ClientHello (and the rest of the connection) to the
> appropriate server. In no SNI, there is a default server (which is where
> most of the traffic is going anyways)
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Nov 2013 06:13:35 -0800

> ALPN could be encrypted as well (same reason, same solution).

What am I missing here, how do you turn on encryption before the client
sees the encryption credential.

Sure you could soft encrypt under a non authenticated key, but that does
not provide a lot of security.

As for economic issues 'not being a consideration', if the group does not
make TLS 1.3 viable commercially then either nobody will use it or the
commercial providers will fork. We have already had two forks in PKIX
because people refused to consider practicality over ideology.

Multihosting is not becoming less common, it is becoming more so. We cannot
burn one IPv4 address per session. And if we did the mapping of domain to
IP address would become 1:1 and the name would leak anyway.

Modern multihosting is dynamic. The provider has no idea which machine a
site is going to pop up on and it can change from day to day. Any scheme
that required all certs to be issued by the same provider is going to be
unacceptable.

-- 
Website: http://hallambaker.com/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 Nov 2013 09:28:16 -0500

> sees the encryption credential.

e.g. using a PFS key exchange, you could include the SNI data after the
key negotiation, but before the server certificate. (i think this
introduces an extra round trip)

> not provide a lot of security.

it provides confidentiality in the face of a passive attacker, which is
specifically what is being asked for.  I think it's clear that this
information is not possible to hide from an active attacker who is
willing to cause connection failures to find out the name of the server
the client is trying to reach.

	--dkg

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 12 Nov 2013 14:56:26 +0000

Hi,

> sees the encryption credential.
The certificate does not contain the encryption credentials.
The certificate can be transmitted after encryption has started.

- server/client: negotiate credentials (not certificate), start encryption
- client: send SNI, ...
- server: send certificate, ...
- authenticate (HMAC over all data that has been send and received during
handshake).

(This is incomplete. Please refer to the protocol-flow that Eric showed at
the IETF88 TLS WG gathering.)

> because people refused to consider practicality over ideology.

absolutely. The believe is that Tansport-Layer-Security (encrypted SNI)
will be more widely adapted than Transport-Layer-Kind-Of-Security
(cleartext SNI leakage). Surely for those Atheist in Saudi Arabia or the
Alan Turing's in Britain it would be bad to have the SNI leaked....

>
> Multihosting is not becoming less common, it is becoming more so. We
> cannot burn one IPv4 address per session. And if we did the mapping of
> domain to IP address would become 1:1 and the name would leak anyway.
>

correct. That's why we have SNI (encrypted or not. both serve this purpose).

> that required all certs to be issued by the same provider is going to be

I agree.

regards,

ralf

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Nov 2013 19:50:35 +0100 (CET)

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
[ Charset UTF-8 unsupported, converting... ]
> the client is trying to reach.

Browsers perform the reconnect fallback failures transparently and
silently, and NSA hat their Foxacid servers in place to shoot down
any TLSv1.3 requests they like with a TCP RST.

A single connection failure per client&server pair per day would be
sufficient to elicit cleartext SNIs from clients & cleartext certificates
from servers.

We should design our protocol to provide security in a robust and
resilient fashion, not in a brittle "weather permitting" fashion
that is being suggested.

-Martin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 Nov 2013 14:10:25 -0500

> any TLSv1.3 requests they like with a TCP RST.

I note that you're talking about an active attacker here.

But in general, yes, any tool that silently performs a fallback to an
older version will not get any of the security enhancements offered by a
newer version.  This doesn't mewn we shouldn't try to add any security
enhancements to newer versions, though.  It means we should try to
figure out ways to discourage fallback, or to identify and isolate and
expose peers who require these fallback mechanisms.

> sufficient to elicit cleartext SNIs from clients & cleartext certificates

Yes, it would, i agree.  These mechanisms seem unlikely to protect the
requested identity of the server in the face of an active attacker.  If
we assume that the client has never connected to the server before (i.e.
no pre-cached server public keys, etc), then i don't see any way to
design a protocol that could hide the identity of the party that the
client is trying to reach from an active attacker who is willing to
cause connection failures.  Do you?

> resilient fashion, not in a brittle "weather permitting" fashion

That's exactly what this discussion is trying to do.  It's clear that
the current SNI mechanism always leaks the requested server identity to
anyone on the network path.  The proposal to encrypt it with keys
derived from the as-yet-unauthenticated DH exchange will hide this
information from any passive attacker on the network path.  It even
allows the client to detect a failed connection (and possible requested
server name leak) when an active attacker attempts a MITM.  These are
both a clear improvements over the current situation.

If you have a proposal for a way to hide this information from everyone
on the network path, including active attackers who are willing to cause
connection failures, that would be an even better improvement.

	--dkg

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 12 Nov 2013 20:01:14 +0000

Martin,

I disagree.

1. The user can decide to force TLS 1.3
2. The attack that you describe requires active packet injection. We just
increased the cost for the attacker from passive recording of data to
active packet injection. Active packet injection does not scale and is
detectable. The proposed solution solves pervasive surveillance. That's the
goal.

I hear you loud and clear that you wish for a protocol where the SNI is
transmitted encrypted _and_ without the attacker
being able to reveal the SNI during an active attack. I'm certain that a
proposal by you of how to do this would be highly appreciated and
educational to the readers.

regards,

ralf

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Nov 2013 21:22:45 +0000

> any TLSv1.3 requests they like with a TCP RST.

I think it would actually be worse than that. Browsers don't want reconnect fallback. So whatever TLS 1.3 looks like, the ClientHello that browsers send will be such that it can be accepted by at least TLS 1.0 servers (and there are plenty of those around). And as others have mentioned, SNI is needed in many cases. Without it, https://www.gmail.com will give you a certificate error.

So you might have a clientHello that leads to super-duper TLS 1.3, but to avoid the need for fallback, you include the SNI (and presumably ALPN) in the ClientHello.

When can we actually avoid having them in the ClientHello?  When servers without TLS 1.3 become such a rarity, that browsers can take the cost of a fallback every time they hit such a server. When will TLS 1.3 penetration reach 95%?

When can we actually remove fallback to <1.3 in our browsers?  When servers without TLS 1.3 become such a rarity, that browsers can live with not supporting those servers. That's pretty much where SSLv2 is, maybe SSLv3. When will TLS 1.3 penetration reach 99.9%?

Yoav

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Nov 2013 22:41:15 +0100 (CET)

> 1. The user can decide to force TLS 1.3

Dumping this kind of decision onto the user is going to make
things worse -- on average and in the long run.

(see also the findings in "Alice in Warningsland"
  http://www.cs.berkeley.edu/~devdatta/papers/alice-in-warningland.pdf

> detectable. The proposed solution solves pervasive surveillance. That's the

You're misrepresenting the issue.  For a passive observer, i.e. someone
watching the media where the connection data travels, inserting a
fake IP datagram with TCP RST in it is **TRIVIAL**, i.e. the cost is
infinitesimal close to zero.  A man-in-the-middle requirement would
be real cost, but we do not have that here.

We already *KNOW* that the FiveEyes folks doing the pervasive surveillance
have their active attack servers in place (Foxacid, Quantum, ...),
so you will actually obtain zero protection here.

> educational to the readers.

I never said that.

What you seem to be looking for is a protocol where an observer does not
know which parties are talking.  That will either require fully dynamic
addresses for both communication peers, pre-shared keys and out-of-band
protected&secure discovery where to find the dynamic address of the
communication acceptor.  Or require the use of a bunch of third parties
like a TOR network, which will hide who is talking to whom.

This is not something you can solve with a few tweaks of the TLS protocol.
And may get the consumers of TLS in big trouble if you continue boasting
that you could achieve this, because some might fall for this myth.

-Martin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 19 Nov 2013 11:46:07 +0000

Hi Martin,

On Tue, Nov 12, 2013 at 9:41 PM, Martin Rex <[email-masked]> wrote:

> Ralf Skyper Kaiser wrote:>

It is technically trivial to insert a TCP RST. It is a whole different
matter in real life. For example does
the US operate under a certain policy that allows for passive monitoring
but would only allow
for active packet injection (TCP RST) under special circumstances.

The claim stands: With encrypted SNI we just raised that bar for pervasive
surveillance. Not just the technically
(doing millions of TCP RST's on every TLS 1.3 connection - undetected - is
not as easy in the real world as you say it
is - especially the undetected part) but also policy wise do we raise the
bar.

> like a TOR network, which will hide who is talking to whom.

No. Not at all. What I'm looking for is encrypted SNI and the browser to
stop advertising
in advance which server I'm connecting to. (On a side note there is a lot
of work
progressing in the DNS community for making DNS confidential. Now is the
time to
fix the last leg that leaks the domain name: SNI).

> that you could achieve this, because some might fall for this myth.

It fact it can be solved with a tweak in TLS 1.3. See Eric's IETF88
presentation.

regards,

ralf

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 19 Nov 2013 13:21:05 +0100

2013/11/8 Watson Ladd <[email-masked]>

> Why wasn't this fixed years ago?

This is not an easy question to answer.  (Yes, it certainly *should* have
been fixed years ago.)

> The client should indicate the

See https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00 for a
proposal intended to be particularly simple.

(This is not the first proposal in this spirit; see, e.g.,
http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt.
 A recurring complaint is that TLS instead should promote interoperability,
which I think is not a valid complaint: While interoperability should be
better than it is, (1) this doesn't extend to interoperability with
attackers, and (2) it's a false dichotomy --
deploying draft-bmoeller-tls-downgrade-scsv-00 would deal with security
problems that arise as implementations work around interoperability
problems, but that I-D won't get in your way in any way, shape or form if
you do in fact manage to avoid those interoperability problems that
currently are often handled by version downgrades.)

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Tue, 19 Nov 2013 23:21:19 +0000

From: Ralf Skyper Kaiser
> > > No. Not at all. What I'm looking for is encrypted SNI and the browser to stop advertising
> > > in advance which server I'm connecting to. (On a side note there is a lot of work
> > > progressing in the DNS community for making DNS confidential. Now is the time to

> > that you could achieve this, because some might fall for this myth.

I think what Martin may be referring to is that to provide this protection against
active MitM attackers generally requires an additional round trip.

> It fact it can be solved with a tweak in TLS 1.3. See Eric's IETF88 presentation.
> regards,

This was my prior suggestion which functions as an extension to 1.0. Posting it here mainly
In case anyone was interested to see how big of a 'tweak' that requires.

http://www.ietf.org/mail-archive/web/tls/current/msg08722.html

- Marsh

Usual disclaimers apply, my own personal opinions, etc.

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 28 Nov 2013 11:06:02 +0000

Hi,

Twitter shared some interesting statistics after enabling ECDHE

https://blog.twitter.com/2013/forward-secrecy-at-twitter-0

The key statistic relevant to this discussion is the impact of an extra
round trip during the handshake. Twitter states that most requests do not
require a full handshake:

"HTTP keepalives and session
resumption<http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html>mean
that most requests do not require a full handshake, so handshake
operations do not dominate our CPU usage."

This is great news for encrypted SNI and ALPN.

Any more statistics welcome.

Increased security for everyone. Neglectable performance impact in limited
circumstances.

regards,

skyper

---

From: Geoffrey Keating <[email-masked]>
Date: 28 Nov 2013 13:56:24 -0800

Ralf Skyper Kaiser <[email-masked]> writes:

> "HTTP keepalives and session resumption mean that most requests do
> not require a full handshake, so handshake operations do not
> dominate our CPU usage."
> 

To take advantage of this, a server using encrypted SNI and/or ALPN
must be able to determine the SNI/ALPN information from the session
resumption data.  I guess this is not too much of a problem, since the
usual reason you can't do this is that you have some kind of front-end
'server NAT' or load balancer which redirects connections to back-end
servers based on SNI/ALPN without doing any cryptography, and this
would be impossible with encrypted SNI/ALPN anyway.