Subject: [TLS] "Encrypted" SNI

From: Hubert Kario <[email-masked]>
Date: Wed, 10 May 2017 19:28:51 +0200

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make 
sure that the client and server agree on the host that the client wants to 
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
the salt and the resulting hash, making the server calculate the same hash 
with each of the virtual host names it supports and comparing with the client 
provided value?

(apologies if that was already proposed and rejected)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 10 May 2017 14:25:22 -0400

> On May 10, 2017, at 1:28 PM, Hubert Kario <[email-masked]> wrote:
> 

There in many cases way too many virtual host names for the server to test.

On the other hand, the attacker with fast hashing silicon can perform the
same computation very quickly.  The virtual hosts supported by the remote
server are likely not much a secret in most cases.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 10 May 2017 20:47:13 +0200

On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote:
> > with each of the virtual host names it supports and comparing with the
> > client provided value?
> > 

if you have tens of thousands of websites you either have a farm of servers, 
so you can solve that with sharding, or the websites don't get much traffic so 
it's not a performance problem

> same computation very quickly.

But it does make simple keyword matching on hostname much harder or 
impossible.

>  The virtual hosts supported by the remote

that's argument for not spending too much resources on the encryption/
obfuscation, not that we shouldn't do it.

But in general, I wonder if we didn't approach the SNI from the wrong side - 
as I said, we may not need to encrypt it, we just make sure that client and 
server agree on the virtual host the connection is going to.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 10 May 2017 15:04:53 -0400

> On May 10, 2017, at 2:47 PM, Hubert Kario <[email-masked]> wrote:
> 

They can do that with a name in the clear.  If the name is to be hidden
from passive observers, then you do need encryption so that only the
client and server, and not the passive observers, can recover the name.

Encryption means key agreement, and requires delaying SNI by a round-trip,
or having published DH shares in DNS, which of course also needs privacy
protection for SNI encryption to matter.

I do believe this was discussed at some length previously.

-- 
-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 May 2017 19:09:28 +0000

> protection for SNI encryption to matter.

With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible.  

A am long overdue for a writeup on this.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 May 2017 12:12:34 -0700

> I do believe this was discussed at some length previously.
It certainly was. But then the clear text SNI is a gaping privacy hole
in TLS, the kind of issue that should keep us awake at night until it is
resolved. We need to make sure that we make progress, rather than rehash
the old arguments. Maybe we should invest some time and document the
various proposals in a draft. I am willing to work on that. Any other
volunteers?

-- Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 May 2017 14:15:01 -0500

> various proposals in a draft. I am willing to work on that. Any other

It seems like there are a number of ways to encrypt the SNI for the
*second* (and subsequent) exchange with a given server; I have one that
I have some notes on and might try to write up.  But do we think that's
worth doing, or do we want to also provide protection for the initial
contact?  It seems like there is a qualitative difference, there...

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 10 May 2017 22:28:48 +0300

> with each of the virtual host names it supports and comparing with the client 

What makes encrypting SNI nasty is replay attacks.

There also was proposal for putting SNI mapping into DNS (which limits the
leakage if DNS lookups are private). However, I came up with a way to use
that to attack HTTPS (the usual "default vhost" attacks).

-Ilari

---

From: Roland Zink <[email-masked]>
Date: Wed, 10 May 2017 23:40:15 +0200

The SNI extension is optional, so you don't have to send the literal 
value. Indeed quite some number of apps do not send it. Browsers 
currently can't know if the SNI is required by the origin servers and 
usually send this, but there could be some signal to not send it. One 
example could be a HTTP header to tell the browser that SNI should be 
send and if it isn't present then no SNI is send. Unfortunately this 
would break current sites but still it can be done the other way around 
e.g. send a header to not send SNI.

Regards,

Roland

Am 10.05.2017 um 19:28 schrieb Hubert Kario:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 May 2017 14:50:50 -0700

On 5/10/2017 2:40 PM, Roland Zink wrote:
> would break current sites but still it can be done the other way
> around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema

---

From: Roland Zink <[email-masked]>
Date: Thu, 11 May 2017 00:03:15 +0200

Not necessarily as you may for example use the path part of a URL to 
distinguish between services.

Roland

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 10 May 2017 16:24:05 -0400

> various proposals in a draft. I am willing to work on that. Any other

I agree with Christian's assessment of the problem, and i'd be
interested in collaborating on such a draft.

The DNS folks are making strides to protect name information (the other
main place where this kind of data is leaking).  TLS needs to keep up.

    --dkg

---

From: Hubert Kario <[email-masked]>
Date: Thu, 11 May 2017 12:59:40 +0200

> What makes encrypting SNI nasty is replay attacks.

What if we specify that the salt is the client key share?

---

From: Hubert Kario <[email-masked]>
Date: Thu, 11 May 2017 12:58:21 +0200

On Wednesday, 10 May 2017 21:04:53 CEST Viktor Dukhovni wrote:
> > But in general, I wonder if we didn't approach the SNI from the wrong side
> > - as I said, we may not need to encrypt it, we just make sure that client
> > and server agree on the virtual host the connection is going to.
> 

You are going in the exact direction I'm saying we should not go, for the same 

> I do believe this was discussed at some length previously.

There are multiple schemes that allow the peers to make sure that both of them 
mean X without outright saying "X". Salting and hashing is one, including it 
in key exchange, (SRP style) is another.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 11 May 2017 10:31:26 -0400

> interested in collaborating on such a draft.

Who's the audience for that draft?  If it's meant to document the blind
alleys we've found, perhaps we could list both alleys, and the walls at
the end:

  - hash the name [adversaries can hash too]
  - hash the name with a salt [adversaries can check the salted hash
    too, as if operating all the banned sites]
  - encrypt the SNI under the pre-shared key

But beware of:

  - the adversary can replay this SNI and see what site he gets
  - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
    no operations that scale linearly with number of sites hosted)
  - not everybody's going to do this, not even every TLS 1.3 instance
  - if networks can't track activity, some will push users to stay on
    TLS 1.2.

-Brian

-- 
Brian Sniffen
Akamai Technologies

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 May 2017 10:21:36 -0400

> distinguish between services.

if we're talking about HTTPS, this approach raises a series of potential
security issues thanks to the same-origin policy and other host- or
domain-specific features of the web security model.  It doesn't solve
the situation where you'd like the services to be independent.

                --dkg

---

From: Hubert Kario <[email-masked]>
Date: Thu, 11 May 2017 20:01:58 +0200

>     no operations that scale linearly with number of sites hosted)

Doesn't that create a Catch 22?

I need to get the key to encrypt the SNI. But if we don't want the names to 
leak, how do I authenticate the key without telling the server what 
certificate I will accept to authenticate the key?

That doesn't look to me like a problem we can solve with typical symmetric or 
asymmetric crypto - it looks to me like more of a zero-knowledge proof issue.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 May 2017 18:35:14 +0000

> asymmetric crypto - it looks to me like more of a zero-knowledge proof issue.

No zero-knowledge schemes come to mind that are suitable to this task.

What can work, but costs latency is to do anon-(EC)DH key agreement
first, and only *then* exchange certificates under the established
keys and sign the session transcripts as required.  That is enable
encryption first, and authentication second, with SNI sent after
you have an unauthenticated encrypted channel.

Yes, an active MiTM attack could capture the SNI, but it would
prevent full session establishment, and so would be tamper-evident.

(One might imagine that initial opportunistic crypto being TCPinc,
with channel bindings extracted into a light-weight authentication
protocol on top, that no longer needs to do the key agreement bits).

The TLS 1.3 draft protocol, while eschewing weaker crypto primitives,
seems optimized more for lower-latency than for greater resistance
to traffic analysis.  I don't think that you can have both.

To really address the issue, one needs a more complete architecture,
that combines all the relevant bits of TCP, TLS and HTTP, ....
Such holistic (r)evolution is extremely difficult.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 May 2017 22:58:48 -0400

> main place where this kind of data is leaking).  TLS needs to keep up.

Encrypted SNI has been talked to death, and coming up with new schemes that warrant air quotes in the subject around "encrypted" feels like a waste of time. Wouldn't it be better to just focus on finishing the encrypt-all-the-things approach and plan out a way to distribute a host DH key (+ a few params, e.g. port(s)+protocol(s) to use with encrypted hellos) via DNS to encrypt everything straight from the ClientHello? Stick a supported_groups in there as well and we can make HRR unneeded while we're at it. This would also protect against 3rd parties attempting to fingerprint clients via ClientHello parameters. (probably a few other things that could be listed that could be helped, too)

Simply put, some of us were convinced a while ago that encrypted SNI isn't nearly as useful as it first seems, however fully encrypted hellos address that problem and more. I think it'd be better to work towards a more complete solution here than just worrying about SNI.

Dave

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 May 2017 20:17:45 -0700

> Encrypted SNI has been talked to death, and coming up with new schemes that warrant air quotes in the subject around "encrypted" feels like a waste of time. Wouldn't it be better to just focus on f…
The "server DH Key" poses a significant forward secrecy issue. Suppose
that the key is compromised. Now the secret police can find out what
nasty sites was accessed by whom. That can be plus plus not good for
said dissidents.
> Simply put, some of us were convinced a while ago that encrypted SNI isn't nearly as useful as it first seems, however fully encrypted hellos address that problem and more. I think it'd be better t…
EKR did propose a TLS in TLS tunnel back in December 2015:
https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw.
It would effectively encrypt the "inner" Client Hello.

-- Christian Huitema

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 May 2017 01:21:06 -0400

> nasty sites was accessed by whom. That can be plus plus not good for

*This is the current situation.* "If the fix is broken, then it won't be fixed anymore" is not really that compelling of an argument, by itself.

Of course the host DH key has an FS risk; it'd need to have a limited validity time and be rotated regularly. (probably weekly) The private key would need to be protected and managed by the host (not the virtual servers), and the public key would need to be given to the virtual servers to be listed in DNS for their domains. An attacker that can get that private key can revert the security to the current status quo, but the handshake would still set up an ephemeral DH key for FS of everything after the hellos (as is the current case, with the well known caveats with 0RTT data).

An attacker that can reliably exfiltrate or completely control that key/host will almost certainly be able to surviel which virtual hosts are connected to no matter what we do. (or more precisely, I think that any gains you can make there are likely to be a lost cause) The only simple solution virtual servers have there is to not use a host you can't actually trust.

Of course, if everyone just switched to IPv6, everyone can get their own unique IP, the offending virtual server nonsense becomes obsolete, and servers could opt-out of SNI entirely (e.g. via a flag in DNS). (yeah, those IPs are of course trackable, though more easily rotatable, but you're not going to get a perfect solution here without something like Tor)

> It would effectively encrypt the "inner" Client Hello.

Same basic concept, different implementation. TLS tunneling would provide some backwards compatibility; ClientHellos would still look like ClientHellos. I was just suggesting the simple generic route of encrypting everything in a non-backwards-compatible way (sent to a specified port that is set up to only handle that and reject everything else). I'd rather let stupid/incompatible stuff just break if we're designing a new opt-in system.

The argument I'm making here isn't about implementation; it's about what to think about implementing to deal with the issues here.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Mon, 15 May 2017 13:56:44 +0200

On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote:
> *This is the current situation.* "If the fix is broken, then it won't be
> fixed anymore" is not really that compelling of an argument, by itself.
> 
> Of course the host DH key has an FS risk; it'd need to have a limited
> validity time and be rotated regularly. (probably weekly)

you then need mechanism to indicate which DNS key share client is using or all 
the connections would start failing on key rollover. And have to deal with all 
the "fun" stuff related to key rollovers.

> The private key
> would need to be protected and managed by the host (not the virtual
> servers)

yes, the key MUST be assigned to a specific IP, not virtual host

> Same basic concept, different implementation. TLS tunneling would provide
> some backwards compatibility; ClientHellos would still look like
> ClientHellos. I was just suggesting the simple generic route of encrypting
> everything in a non-backwards-compatible way (sent to a specified port that
> is set up to only handle that and reject everything else). I'd rather let
> stupid/incompatible stuff just break if we're designing a new opt-in
> system.
> 
> The argument I'm making here isn't about implementation; it's about what to
> think about implementing to deal with the issues here.

I respectfully disagree. That system requires tight coupling between the TLS 
implementation and DNS. This is not something that facilitates TLS deployment. 
We want more TLS/HTTPS deployment, not less.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 15 May 2017 16:10:00 -0400

> the "fun" stuff related to key rollovers.

It's possible to conceive of a way to do this with minimal trial decryption,
or instead, we could just rotate the port with the key. (confusing firewalls
is of course a problem, but that's something that could be dealt with)

> We want more TLS/HTTPS deployment, not less.

I completely understand why you'd disagree on these grounds. My argument is
that whilst this does require a significant amount of coordination, it's a more
productive route than just focusing on SNI encryption, which still has its own
share of problems. (hence us not agreeing on a way to do it yet)

The most practical short-term route would likely be to continue to hold our noses
and expect cleartext SNI, but maybe provide a very simple way for servers to put
a flag in a DNS record to opt-out entirely when they can do without.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Tue, 16 May 2017 13:35:16 +0200

On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote:
> > I respectfully disagree. That system requires tight coupling between the
> > TLS implementation and DNS. This is not something that facilitates TLS
> > deployment. We want more TLS/HTTPS deployment, not less.
> 
> that whilst this does require a significant amount of coordination, it's a
> more productive route than just focusing on SNI encryption, which still has
> its own share of problems. (hence us not agreeing on a way to do it yet)

Is there anything else sensitive in the Client Hello? Either way, to properly 
encrypt SNI with forward secrecy requires the same system that would be 
necessary to encrypt the whole Client Hello.

> The most practical short-term route would likely be to continue to hold our
> noses and expect cleartext SNI, but maybe provide a very simple way for
> servers to put a flag in a DNS record to opt-out entirely when they can do
> without.

The point of encrypting SNI is so that you can hide a website on a shared 
hosting host. If you have just one website on a host, there's nothing to 
hide... Opting out by servers also makes the interesting targets more visible 
(see also: email encryption).

---

From: Dave Garrett <[email-masked]>
Date: Tue, 16 May 2017 21:50:41 -0400

On Tuesday, May 16, 2017 07:35:16 am Hubert Kario wrote:
> Is there anything else sensitive in the Client Hello?

Yes. (lower priority info, but nonzero) I'm of the philosophy that implementations
should be open to arbitrary audit, but their messages should not give any
info away that it doesn't have to. Frankly, figuring out how it can be misused
is secondary; I assume it can.

A hypothetical scenario: Lets say I've got a client using a device, and moving
between multiple networks (e.g. joins various WiFi over time). Lets say the
attacker is passive and cannot reliably know what the IP of our client is at
all times. The user will most likely consistently use the same client software.
Various different implementations will make various different choices with
the many switches and options in TLS; fingerprinting implementations based
on their ClientHellos is not that hard. If the user has changed anything
from default that affects TLS via hellos, fingerprinting becomes much easier.
This means that an attacker can one, guess what software the target user
is using and make it easier to attack (and possibly decide to use active
attacks at some point), and two, attempt to track a user with a changing IP
across connections. Lets say our user goes through various WiFi networks
and our attacker can listen in on all of them (not necessarily a tall ask), or
we only care about a specific (set of) server(s) and can listen to their traffic.
If the attacker can link the user to one IP, and see its ClientHello, then
it can guess a window where the client switches from one IP to another,
look for ClientHellos, and then narrow down the possibilities of who the
target is in that list based on the prior fingerprint. If unique enough, or
combined with other information to narrow it down further, the client can
be identified across networks. There's of course other reasons clients can
switch between IPs; Tor users can come out of different exit nodes over time.
The point here is that not being able to fingerprint the ClientHello would
make it much harder to track targets across IP changes.

Additionally, whether or not a client is resuming a session is revealed in
the ClientHello. This information can also be used to identify clients, and is
itself potentially private information that the user may not wish to be
disclosed.

I'm sure we could come up with some other bits of information that get
leaked that could be used in some creative way in the future. I also assume
that some implementation will at some point put something incredibly stupid
in its ClientHello that needs extra protection. I'd prefer we just attempt to
always encrypt it all and call it a day. ;)

> Either way, to properly 

I get the impression that some people consider "proper" encryption of SNI
to be something less important than getting it encrypted in any way. (e.g.
a trial hashing idea was brought up) I'm not opposed to attempting to get
a minimum viable SNI encryption scheme out there, but I think those efforts
are better aimed higher. (and doing just SNI makes us less likely to consider
full hello encryption in the future)

> (see also: email encryption).

Point taken, but you can change your IP more often than your domain. Not using
SNI at least increases the amount of effort required to figure out the destination.

Dave