Encrypted SNI Comes to Firefox Nightly • Hacker News Board

Re: Encrypted SNI Comes to Firefox Nightly

#51

Post by js2 » Thu, Oct 18, 2018, 8:15 PM UTC

the8472 wrote: post #25

cremp wrote: post #12

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…

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.

> To use ESNI you need DOH

This is a Firefox decision, not something required by the standard:

https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-7

ESNI is best combined with DoH to prevent snooping (hence Firefox's apparent decision to tie the two features together), but obtaining the ESNI key does not strictly require DoH.

Re: Encrypted SNI Comes to Firefox Nightly

#52

Post by lilyball » Thu, Oct 18, 2018, 8:17 PM UTC

the8472 wrote: post #49

eridius wrote: post #42

Earlier quoted context omitted.

None of this is tied to Cloudflare though. Or really to using a cloud provider at all. Of course, if you're not using a cloud provider, then the IP address can be used to figure out what the site is, but the point remains that you can pick from any cloud provider that supports ESNI (and, separately, pick from any DNS provider that supports DOH). At the moment if you want ESNI it looks like you have to use Cloudflare,…

> (and, separately, pick from any DNS provider that supports DOH). But why do I have to? I already have a trusted DNS resolver operated by myself wired to my OS. Why require the whole DoH rube goldberg machinery to let me try ESNI?

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests generated by your OS-level DNS resolver exactly as they would observe DNS requests generated by your browser.

DOH isn't about trust. It's about preventing network observers from figuring out what sites you visit by observing the DNS requests you make.

Re: Encrypted SNI Comes to Firefox Nightly

#53

Post by the8472 » Thu, Oct 18, 2018, 8:19 PM UTC

lilyball wrote: post #52

the8472 wrote: post #49

Earlier quoted context omitted.

> (and, separately, pick from any DNS provider that supports DOH). But why do I have to? I already have a trusted DNS resolver operated by myself wired to my OS. Why require the whole DoH rube goldberg machinery to let me try ESNI?

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests generated by your OS-level DNS resolver exactly as they would observe DNS requests generated by your browser. DOH isn't about trust. It's about preventing network observers from figuring out what sites you visit by observing the DNS requests you make.

I am perfectly capable of having my DNS resolver use a different, encrypted route than the HTTPS traffic.

This is not mozilla's decision to make.

Re: Encrypted SNI Comes to Firefox Nightly

#54

Post by tombrossman » Thu, Oct 18, 2018, 8:30 PM UTC

mholt wrote: post #27

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 c…

Interesting that you mention the privacy risk of tracking, as this[0] just appeared in my Twitter feed at about the same time I was reading HN.

"Tracking Users across the Web via TLS Session Resumption"[1]. A snippet from the abstract: "Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days. With a session resumption lifetime of seven days, as recommended upper limit in the draft for TLS version 1.3, 65% of all users in our dataset can be tracked permanently."

Not exactly looking forward to TLS1.3, it appears to be a move forward in security but with no (or worse) privacy benefits that I've seen so far.

[0]https://twitter.com/durumcrustulum/status/105293632402455757...

[1]http://front.math.ucdavis.edu/1810.07304

Re: Encrypted SNI Comes to Firefox Nightly

#55

Post by tialaramex » Thu, Oct 18, 2018, 8:38 PM UTC

lilyball wrote: post #52

the8472 wrote: post #49

Earlier quoted context omitted.

> (and, separately, pick from any DNS provider that supports DOH). But why do I have to? I already have a trusted DNS resolver operated by myself wired to my OS. Why require the whole DoH rube goldberg machinery to let me try ESNI?

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests generated by your OS-level DNS resolver exactly as they would observe DNS requests generated by your browser. DOH isn't about trust. It's about preventing network observers from figuring out what sites you visit by observing the DNS requests you make.

Not _only_ about trust. One of the things DoH gets you for free is that it means that your ISP doesn't get to touch DNS requests, which was not true previously. You can get Internet service from whatever bunch of money-grabbing assholes are available where you live, and get DNS from somebody else without that being tampered with since it's encrypted on the wire. You do still have to trust the DoH provider (outside of DNSSEC).

In the UK for example, the current government proposals for yet more Internet censorship assume that they can "just" order ISPs to censor DNS. This, their white paper says, is relatively cheap and so ISPs might even be willing to do it at no extra cost, which is convenient for a supposedly "small government / low tax" party that keeps thinking of expensive ways to enact their socially regressive agenda...

But DoH and indeed all the other D-PRIVE proposals kill that, to censor users with D-PRIVE you're going to have to operate a bunch of IP layer stuff, maybe even try to do deep packet inspection, which TLS 1.3 already made problematic and eSNI skewers thoroughly.

So there's a good chance this sort of thing for _ordinary_ users (the white paper already acknowledges that yes, people can install Tor and it can't do anything about that) makes government censorship so difficult and thus expensive as to be economically unpalatable. "Won't somebody think of the children" tastes much better when it doesn't come with a 5% tax increase to pay for it...

Re: Encrypted SNI Comes to Firefox Nightly

#56

Post by tptacek » Thu, Oct 18, 2018, 8:38 PM UTC

ploxiln wrote: post #48

tptacek wrote: post #19

Earlier quoted context omitted.

Funny, I think we've had exactly the opposite problem . See, for instance, Heartbleed, which is pure product of IETF standardization of a feature no mainstream commercial entity asked for.

It was not required to implement the tls heartbeat feature, and IIRC most tls implementations did not implement it - except for openssl. The real problem there was openssl (and it was a big problem, being both the widespread default choice, and too hairy for most competent engineers to bother to dig into, at the same time ...)

Again, nobody was asking for the Heartbeat feature. I went back and read through the (IIRC?) tls-wg posts about it. The same is true of extended-random† --- 4 different proposals! None of them were really pushed back on. It was just sort of assumed that if nobody strongly objected, it was going to become part of the standard.

DNSSEC is another great example. Look around. Nobody in the industry is asking for it (try that "dnssec-name-and-shame.com" site to confirm this), except the IETF and a very short list of companies with a rooting interest, like Cloudflare. In the very short time it's been around. DNS over HTTPS has done more to improve DNS security than 25+ years of DNSSEC standardization ever did. The cart has been dragging the horse here for a long time.

† https://sockpuppet.org/blog/2015/08/04/is-extended-random-ma...

Re: Encrypted SNI Comes to Firefox Nightly

#57

Post by zamadatix » Thu, Oct 18, 2018, 8:39 PM UTC

zzzcpan wrote: post #44

codetrotter wrote: post #37

Earlier quoted context omitted.

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

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 b…

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

Re: Encrypted SNI Comes to Firefox Nightly

#58

Post by laumars » Thu, Oct 18, 2018, 8:41 PM UTC

pixl97 wrote: post #32

StudentStuff wrote: post #29

Earlier quoted context omitted.

I do not think most webservers will be set up with one IPv6 address per website. As is, most IPv6 enabled sites that share an IPv4 with another site and also share their IPv6 address with those same sites. Assigning one IPv6 address per site would add complexity for little benefit.

Does Apache or nginx still have issues with serving lots of ip's at once. I know a long, long time ago it could be a performance issue.

How long ago are we talking? Apache 1.3? That used to have a few nuances but it's now been superseded several times over. I didn't use 2.0 a whole lot but I don't recall it ever being an issue with 2.2 and we're onto yet another engine rewrite with version 2.4 (which has been available a few years now too).

Re: Encrypted SNI Comes to Firefox Nightly

#59

Post by kardos » Thu, Oct 18, 2018, 8:43 PM UTC

tombrossman wrote: post #54

mholt wrote: post #27

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 c…

Interesting that you mention the privacy risk of tracking, as this[0] just appeared in my Twitter feed at about the same time I was reading HN. "Tracking Users across the Web via TLS Session Resumption"[1]. A snippet from the abstract: "Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days. With a session r…

> with the standard setting of the session resumption lifetime in many current browsers

> seven days, as recommended upper limit

Do we fix this by changing that setting to a few hours?

Edit: the report discusses this: "The recommended upper limit of the session resumption lifetime in TLS 1.3 [19] of seven days should be reduced to hinder tracking based on this mechanism. We propose an upper lifetime limit of ten minutes based on our empirical observations"

Re: Encrypted SNI Comes to Firefox Nightly

#60

Post by zamadatix » Thu, Oct 18, 2018, 8:49 PM UTC

the8472 wrote: post #23

e1ven wrote: post #3

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?

Are there even any DoH resolvers you can run yourself? unbound only supports DoT. It's a shame that they had to invent yet another standard. This makes things a lot more complex to run in a lan. Especially since you also need certificates and put them into the browser trust store. Just to avoid leaking SNI.

The problem was DoTLS was too easily blocked, even by accident with networks that only allowed their DNS server on 53, HTTP on 80, and HTTPS on 443. Easiest way to fix it without giving network administrators a choice unless they control both the devices and the network was to make it ride over HTTPs. Unfortunately I think that means DoTLS is likely to become unused even though it is technically a "cleaner" protocol implementation.

As far as resolvers you can run yourself everyone and their brother has made one - facebook, cloudflare, cordens, dnscrypt, your cousin's brother's sister on Github. Literally all there is to it is rewriting well formed datagrams into well formed JSON and back.