Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)

[Dave Garrett <[e-mail]>]

On Tuesday, May 16, 2017 07:35:16 am Hubert Kario wrote:
> On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote:
> > On Monday, May 15, 2017 07:56:44 am Hubert Kario 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.
> > 
> > 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)
> 
> 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 
> encrypt SNI with forward secrecy requires the same system that would be 
> necessary to encrypt the whole Client Hello.

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)

> > 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).

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