
Encrypted SNI Comes to Firefox Nightly - okket
https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
======
cremp
Is it me or...

> If they’re willing to convert all their customers to ESNI at once

Why does it seem like this is over-engineering at it's finest? Not only are
CDNs now part of the problem/solution space, but they are now dictating.

It is now _that much_ harder to diagnose issues when they do crop up, instead
of checking ping or nslookup. Now, you've got to see if the DNS-over-HTTPS/The
DNS record itself/Host/client/any number of other steps is broken.

We've completely removed the ability for a poweruser to diagnose before
calling their resident IT professional.

~~~
the8472
It's even worse. To use ESNI you need DOH. To use DOH you need a resolver with
a server certificates, which is kindly offered by the same cloud providers. So
now all your base are belong to cloudflare.

~~~
AndyMcConachie
It's even worse because they talk like ESNI is some kind of standard, but
there's only been a single draft at the IETF written by a Mozilla employee,
and that draft is still at version 1. Calm down Mozilla, maybe other people
would like to comment on the design before you go and implement it?

Doing it like this is a great way to end up in interopeability hell down the
road when different parties have implemented different versions. I'm not
saying they _have to_ wait until it's an RFC, but atleast wait for a couple
more versions of the draft and let the IETF discuss it a bunch first. This is
a big change.

~~~
tialaramex
> but there's only been a single draft at the IETF written by a Mozilla
> employee

I can see why it might look that way, but actually draft-ietf-tls-esni-01 is
the third draft of this document, and has been co-written by at least four
named authors including Chris Wood at Apple. Also that "Mozilla employee" was
one of the Working Group chairs.

draft-ietf-tls-esni-01 was preceded by draft-ietf-tls-esni-00 (it is usual for
early drafts to have zero zero versions)

draft-ietf-tls-esni-00 was preceded by draft-rescorla-tls-esni which was Eric
Rescorla's first write-up of this idea

Finally, though this document didn't exist twelve months ago, the "issues and
requirements" document did. This document imports the thinking behind that
document, it just provides an implementation and now Firefox is testing it.

The reason for the name change is a thing called "adoption". The TLS Working
Group agreed by consensus to adopt this piece of work, rather than it just
being independent stuff by a handful of people who coincidentally were working
group members. When that happens the draft's name changes, to reflect the
adoption (removing a single person's name) and sometimes to use more
diplomatic naming (e.g. the "diediedie" draft got a name that didn't tell TLS
1.0 to "die" any more when it was adopted).

------
mholt
So what's the plan for when IPv6 gains more adoption and we don't need SNI as
much since every site can have its own public IP address (thus making tracking
easier, subverting the benefits of encrypted SNI).

Do you think encrypted SNI and NAT will become preferred to using IPv6 for
routing because of the privacy benefits of ESNI (either real or imagined,
depending on who you trust, since this seems to be relying on centralized CDNs
for adoption)?

Edit: I realize ESNI and IPv6 are orthogonal, however, I wanted to ask since I
know that lack of IP space and using NAT/SNI are correlated.

~~~
otabdeveloper2
IPv6 will never gain universal adoption.

Nobody wants their home or their datacenter machines exposed to the whole
Internet all the time.

NAT is a feature, not a bug.

~~~
foresto
That side effect of NAT is easily replaced with a simple firewall. Even today,
many home routers have this capability already by virtue of running linux.
Enabling it would be a pretty simple step for manufacturers.

------
e1ven
I'm curious why this is tied to DNS-over-HTTPS.

It looks like Cloudflare is including a public key in the DNS lookup, which is
used to encrypt the SNI information.

Couldn't this key be stored in a TXT record for normal DNS lookups as well?

~~~
rickbutton
If the public key was stored in a TXT record and accessed via regular DNS,
then someone snooping the connection could see that you made a DNS lookup for
that domain, and could make the reasonable assumption that you were about to
make a request to said domain.

~~~
zzzcpan
Someone could still make a very reasonable assumption based on IP addresses
and response sizes, which is where I believe the primary focus would shift if
by some chance this encrypted SNI becomes impossible to circumvent. But also
someone could just block DNS-over-HTTPS requests altogether and force Firefox
into cleartext DNS and therefore circumvent encrypted SNI.

It also centralizes DNS requests at Cloudflare's POPs (a company from a mass
surveillance, secret orders happy, police country by the way).

No, none of it addresses privacy and security, probably only makes it worse.

It's time to admit there is no future for privacy and security without overlay
networks.

~~~
codetrotter
> someone could just block DNS-over-HTTPS requests altogether

If you are going to block DoH you’ll need to block all HTTPS traffic
altogether, don’t you? I mean unless you are just blocking traffic to some
list of known DoH providers.

~~~
zzzcpan
DoH must be bootstrapped somehow to get IP addresses to make requests to. This
is where it can be blocked. Either blocking DNS query or a known IP address or
just an IP address with suspiciously tiny responses that responds to active
probing requests as a DoH server. It's very hard to hide that fact, you need
to actively fight those blocking attempts. And if it's done by some
government, corporations just bend over backwards to help censorship, like
they did in cases of Signal and Telegram recently for example.

~~~
zamadatix
>This is where it can be blocked. Either blocking DNS query or a known IP
address or just an IP address with suspiciously tiny responses that responds
to active probing requests as a DoH server.

This works great in theory but if it takes off then Google and Cloudflare can
simply decide to serve DNSoHTTPS requests over their existing service IP space
and you're left with the choice of block the internet or allow encrypted DNS
lookups.

As far as government comments you're never going to deploy public
infrastructure inside a state and be able to avoid the state so it's pointless
to bring anything about that up.

------
markovbot
This sounds great. Does anyone know if any web servers are planning on
implementing it?

~~~
duskwuff
ESNI is primarily a feature of the SSL implementation, not of the web server.
As far as I'm aware, it's not in OpenSSL yet, but is likely to be added once
TLS 1.3 has been finalized.

------
seccess
Hey I just recently complained about SNI on a recent HN thread
([https://news.ycombinator.com/item?id=18223168](https://news.ycombinator.com/item?id=18223168)).
This is a lovely coincidence. Thanks Mozilla!

------
nykolasz
I would love to understand why Firefox keep adding support for CloudFlare
specific features.

~~~
dagenix
Thats not remotely true. ESNI is a draft IETF spec -
[https://datatracker.ietf.org/doc/draft-ietf-tls-
esni/](https://datatracker.ietf.org/doc/draft-ietf-tls-esni/). It just so
happens, that right now CloudFlare and Firefox are the ones that implement it.
But any particular feature, regardless of how great it is or how well
specified by a standards body, must have a first implementation by someone.
And it's really not that shocking that a group like CloudFlare wants to be at
the forefront of new web technologies AND also has the resources to pay for
it. What does boggle the mind that is that everyone freaks out when a draft
IETF standard is implemented. What do people want? For it to spring into
existence fully formed implemented by all browsers, operating systems, DNS
software and providers, etc all that once? That would be ridiculous - and
worse, if there aren't a few experimental implementations to work out the
issues, even if that could happen, what would be implemented would probably
have significant issues that we'd then be stuck with forever.

------
ex3ndr
Does this mean that this change will add yet another roundtrip?

~~~
caf
No, it's bootstrapped from an additional DNS record type (which presumably
would be returned alongside the A record).

See [https://blog.cloudflare.com/encrypted-
sni/](https://blog.cloudflare.com/encrypted-sni/) .

------
comesee
As a cancer survivor, using the example of someone spying on your cancer.org
visit as a motivation for encrypted SNI seems a bit excessive and insensitive.
There are definitely more neutral ways of motivating eSNI than invoking the
fear of a stranger finding out you or a loved one has cancer. Shame on
Mozilla.

~~~
mort96
I get you, but I suppose the most obvious alternative examples are things like
porn or illegal sites, which they might not have wanted to use. What
alternative examples would you have preferred?

Apple's contrived example from when they introduced private mode in Safari was
shopping for presents and not wanting the recipient to find out, but that
would be even less convincing when the person you're hiding your traffic from
is the person next to you in the coffee shop.

~~~
comesee
The coffee shop being able to know all the domains you're visiting without
your consent is already bad enough. I don't think they need to draw out a
specific example. If the idea of the coffee shop knowing all the websites we
visit is bad, we'll come up with our own examples, and that's something
everyone can do. Almost no one researches cancer online.

