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

121–130 of 155 posts

Re: Encrypted SNI Comes to Firefox Nightly

#121

Post by zingmars »

hueving wrote: post #87
Someone1234 wrote: post #33

Earlier quoted context omitted.

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

>- Discourage users visiting via the IP Address, adding that to favorites, sharing it, etc. Making it difficult/impossible to migrate That's not a reason to reject. That's a reason to issue a redirect. No regular user that would make the mistake of bookmarking an IP instead of a domain is going to know how to use an IP to get there in the first place. >- Make it harder for databases to associate that IP Address with…

>No regular user that would make the mistake of bookmarking an IP instead of a domain is going to know how to use an IP to get there in the first place. System admins probably have caught up to this now, but a decade back I remember non-techy people doing just that. Turns out their sysadmins had blocked some social networks and people found out that you can still access the site using an IP address of their servers. The IP addresses themselves were spread across the office and many people ended up with bookmarked IP addresses. So yes, it could and has happened.

Re: Encrypted SNI Comes to Firefox Nightly

#122

Post by maccam94 »

gregmac wrote: post #102
jeroenhd wrote: post #31

Earlier quoted context omitted.

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

More than that, why bother? If I use SNI -- which at this point is fully supported on anything that matters -- I just have to setup all the hosting definitions and make sure my server can find all the certificates. If I want to use one IP per site without SNI, now I have to also manually manage the mappings of IP-to-certificate for each host, and also be sure they're all synchronized with DNS. More work, more potenti…

Certificates are tied to hostnames, and hostnames resolve to IPs. You could have a server with 50 IPv6 IPs, have a different hostname resolve to each one, and load all of the SSL certs onto the machine along with the appropriate webserver configs. You could then add IPs to the server and DNS without touching the certs. Or replace a cert without changing anything else. You don't need SNI in this scenario, you just have to ensure you add the new IPs to the server configs before updating DNS, so it will serve the correct default certificate.

Re: Encrypted SNI Comes to Firefox Nightly

#123

Post by auslander »

jopsen wrote: post #36
the8472 wrote: post #25

Earlier quoted context omitted.

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.

Thing is, it does bargain, and trusts third-party privacy policy, but I, for example, do not trust Cloudflare.

"We’ve chosen Cloudflare because they agreed to a very strong privacy agreement" [0]. Like, legally agreed? With regular audits and full access for Mozilla people?

Where does that leave me, if it gets baked into my browser?

[0] https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...

Re: Encrypted SNI Comes to Firefox Nightly

#124

Post by vetinari »

yjftsjthsd-h wrote: post #104
vetinari wrote: post #64

Earlier quoted context omitted.

There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs. Each client that wants to use DNS using any protocol will have to contact it by IP first, and that IP has to be provisioned somehow. The same mechanism used for provisioning can be used for blocking.

So preload the list of IPs in the OS.

That's the easy case, if they are preloaded in the OS, they are well-known by definition and can be blocked statically.

The dynamically discovered ones are the next step in the game, but you still have to start somewhere, either with well-known IP or at least legacy DNS.

Re: Encrypted SNI Comes to Firefox Nightly

#125

Post by jgrahamc »

auslander wrote: post #123
jopsen wrote: post #36

Earlier quoted context omitted.

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.

Thing is, it does bargain, and trusts third-party privacy policy, but I, for example, do not trust Cloudflare. "We’ve chosen Cloudflare because they agreed to a very strong privacy agreement" [0]. Like, legally agreed? With regular audits and full access for Mozilla people? Where does that leave me, if it gets baked into my browser? [0] https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...

The quote you make there from your reference [0] has a link to the legal agreement with Cloudflare. It's here: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... So you can read the legal agreement.

Of course, if you still don't want to use Cloudflare for DoH you can just configure your favourite resolver in Firefox itself. The blog you refer to as [0] contains detailed instructions on how to do that.

So, where are you left? Right where you are today: you control the DNS resolver on your machine today. With Firefox Nightly you also control the DoH resolver (and can disable it entirely).

Re: Encrypted SNI Comes to Firefox Nightly

#126

Post by ComodoHacker »

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…

After IPv6 adoption it can be made a legal requirement to have unique IPv6 address for every unique domain name.

Re: Encrypted SNI Comes to Firefox Nightly

#127

Post by rocqua »

ComodoHacker wrote: post #126
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…

After IPv6 adoption it can be made a legal requirement to have unique IPv6 address for every unique domain name.

Having AAA records be one-to-one would be a massive change to DNS.

Re: Encrypted SNI Comes to Firefox Nightly

#128

Post by rocqua »

why_only_15 wrote: post #106
bscphil wrote: post #103

Earlier quoted context omitted.

Maybe I'm misunderstanding, but isn't the point of the GP that as IPv6 takes over, eSNI becomes practically useless since it's possible for every site to have its own IP address? If I'm connecting to an IP address that only maps to one site, then Bob is going to be able to figure out what that site is. You're right that eSNI is a nice to have (though years late) for IPv4, but I and the GP would like to know what we c…

I might be misinterpreting this, but on IPV6 do CDNs keep separate addresses for different sites? I suppose it would move things up a protocol level - instead of specifying it in HTTP we can specify it in IP. However, the key issue is CDNs here. In almost no other circumstances do different websites keep the same IPV4 address.

> In almost no other circumstances do different websites keep the same IPV4 address.

I have multiple domains hosted on my personal site. Similarly, facebook.com and facebook.co.uk could very well point to the same IPs.

Re: Encrypted SNI Comes to Firefox Nightly

#129

Post by rocqua »

floatingatoll wrote: post #85
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?

DNS is plaintext, like HTTP, so running your own resolves does nothing to protect your internet provider from selling your domains resolved list - in aggregate or in specific - to other companies for revenue. There are three well-known trusted public DNS resolvers, run by Cloudflare, Verizon, and Google. Which of those three would you encrypt your DNS traffic to, if those were the only three options available other t…

I think the specific question is: Why prefer `DNS over HTTPS` over e.g. `DNS over TLS`. The relevant matter is that DNS requests are encrypted. How exactly it is encrypted should not matter.

Re: Encrypted SNI Comes to Firefox Nightly

#130

Post by rocqua »

dagenix wrote: post #92
tptacek wrote: post #69

Earlier quoted context omitted.

DoH drastically reduces the impetus for the deployment of DNSSEC; it is essentially the 2018 answer to DNSCurve/DNSCrypt. Google and the Chrome team have been pretty clear about what they think about DANE's prospects moving forward. And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for…

And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ . He makes the excellent point that DNSSEC (and thus DANE) doesn't get rid of CAs at all - it just makes whoever controls the domain into a defacto CA. Yeah, Comodo behaved badly as a CA - so, the browsers are in the process of no longer trusting it; imagine if DANE were in widespread use…

> "Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.

The common counter-point is that, because nearly every CA does domain validation, the owners of the DNS keys are already capable of getting arbitrary certs. Therefore, DANE does not give DNS key owners more power; all it does is take out the CA's as a potential failure point. And really, as long as a cert attests that "You are talking to the owner of this domain" the power over certs is always going to lie with those who control the DNS system.

A possible response is that just taking power from the CA's but leaving power with the DNS key owners is not good enough. This does make some sense. It is not entirely clear to me how we will take this power from the DNS system though. The best bet are CT-logs, which will allow after-the-fact detection of any falsely issued certs. Notably though, attribution between CA's and the DNS system isn't solved here. Perhaps if CA's store the relevant signed DNS response, we could attribute the attack to the DNS system.

Post reply on HN