Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encrypted SNI Comes to Firefox Nightly

blog.mozilla.org

Post reply on HN
Print view View original

31–40 of 155 posts

Re: Encrypted SNI Comes to Firefox Nightly

#31

Post by jeroenhd »

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…

I think SNI will remain in fashion even after IPv6 is introduced globally. SNI works fine for plain IPv6 address.

If you run multiple websites on a single server for example you can move your server to another IP address / host / datacenter, update the IP address in your DNS settings and you're done. If you use IPv6 for this purpose, every domain and subdomain need to be configured with a new IP address and need a special line in the DNS config. This leads to administrative overhead, which leads to mistakes.

Re: Encrypted SNI Comes to Firefox Nightly

#32

Post by pixl97 »

StudentStuff wrote: post #29
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…

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.

Re: Encrypted SNI Comes to Firefox Nightly

#33

Post by Someone1234 »

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…

You could ignore the eSNI on the web server completely if you wished. But even on HTTP servers serving only a single IP it is still typical to only respond to requests targeting the correct hostname (i.e. direct IP requests are bounced).

There's numerous reasons to bounce direct (non-hostname) requests including:

- Discourage users visiting via the IP Address, adding that to favorites, sharing it, etc. Making it difficult/impossible to migrate.

- Make it harder for databases to associate that IP Address with your site (for user privacy).

- Security. Ignoring that several modern techniques don't even work with IP Addresses, it also stops someone taking over the IP after you migrate and stealing cookies associated with that address, etc.

Point being is, that SNI is useful on IPv6. It is useful on single web-site servers. It isn't going anywhere.

Re: Encrypted SNI Comes to Firefox Nightly

#34

Post by cremp »

drb91 wrote: post #21
cremp wrote: post #17

Earlier quoted context omitted.

They can't, because that's handled at the OS level, not the application level. If a browser starts (purposefully) subverting the hosts file or not adhering to resolv addresses, then we've got a bigger problem. Think, a fat client resolving an address differently than a browser; then that's all sort of Pandora's Box.

DNS over HTTPS is still handled at the OS level? Related, it should be possible to have “correct” dns in userland that behaves as you describe sans falling back to the system resolver. In my understanding the whole point of DNS over https is to avoid the DHCP assigned DNS address (and of course encrypt) Finally, I’m pretty sure Firefox at least does its own dns caching. I’ve had to force reload to pick up dns changes…

DoH isn't done by the OS. But that's my point. In order to use DoH, you have to (purposefully) use an extension/browser addon/browser setting.

As a system admin myself; if user applications started overriding the DHCP DNS that I give them, not only could intranet sites be broken, but I'd start having fights with users about it.

Edit: Rather, not overriding but querying the DoH instead of the provisioned DHCP DNS. I'm no expert in DoH, or how any of that works under the hood.

Further, when/if browsers turn on DoH by default, then I can't really fight users, because they did nothing wrong but use a browser. Suddenly, I can't support a browser or two because of it.

DNS caching by the application is fine, because they made the request to the OS, and got the response. That being said, TTL might be violated by that, since the record has a TTL, and whatever the application cache TTL is.

Re: Encrypted SNI Comes to Firefox Nightly

#35

Post by the8472 »

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…

Hosters could play games with IPv6-hopping to make tracking/reverse association more resource-intensive. Their nameservers could even return different addresses for different regions. I doubt many will do that, then again hiding behind SNI never gave you any added anonymity in the first place unless you happend to end up on some shared reverse proxy in the first place.

Re: Encrypted SNI Comes to Firefox Nightly

#36

Post by jopsen »

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.

But if you're using CloudFlare through Firefox, Mozilla is doing collective bargaining on your behalf.

It's a different world, true, but technology can't be stopped. If Mozilla succeeds in being a agent negotiating on behalf of users, all your base might be governed by reasonable contracts.

Re: Encrypted SNI Comes to Firefox Nightly

#37

Post by codetrotter »

zzzcpan wrote: post #24
rickbutton wrote: post #4

Earlier quoted context omitted.

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.

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

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

Re: Encrypted SNI Comes to Firefox Nightly

#38

Post by AndyMcConachie »

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.

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.

Re: Encrypted SNI Comes to Firefox Nightly

#39

Post by vetinari »

toomuchtodo wrote: post #30
zzzcpan wrote: post #28

Earlier quoted context omitted.

> There are benefits (censorship circumvention) to be reaped, but also great peril. There is no way this encrypted SNI could enable censorship circumvention.

My understanding was that encrypted SNI was to avoid the sniffing of the host header that travels unencrypted with SNI, and that in combination with a large host (Cloudflare, Google, AWS), an encrypted SNI prevents censorship (unless you're dropping all traffic to the IP block or AS). Is this understanding inaccurate?

If you are state-level actor wanting to censor, the ISPs in your country you will ask politely the large host (Cloudflare, Google, AWS) to cooperate and drop any traffic coming for the censored domain from their IP ranges.

Only if the large host does not cooperate, the respective ISPs will block their entire IP range, (if they want to keep operating in given jurisdiction).

Re: Encrypted SNI Comes to Firefox Nightly

#40

Post by toomuchtodo »

vetinari wrote: post #39
toomuchtodo wrote: post #30

Earlier quoted context omitted.

My understanding was that encrypted SNI was to avoid the sniffing of the host header that travels unencrypted with SNI, and that in combination with a large host (Cloudflare, Google, AWS), an encrypted SNI prevents censorship (unless you're dropping all traffic to the IP block or AS). Is this understanding inaccurate?

If you are state-level actor wanting to censor, the ISPs in your country you will ask politely the large host (Cloudflare, Google, AWS) to cooperate and drop any traffic coming for the censored domain from their IP ranges. Only if the large host does not cooperate, the respective ISPs will block their entire IP range, (if they want to keep operating in given jurisdiction).

All roads lead to layer 8.
Post reply on HN