Hacker News Reader

Comment by Vinnl | Hacker News Reader

I think this is generally a good thing. Two questions I've often seen surface on HN though weren't answered:

1. Isn't this better implemented at the OS level?

2. Isn't centralisation to two DoH providers more centralised than five large ISPs?

Others are probably better suited to answer, but the answers I can think of:

1. Yes, but it is not, so this solution is second-best. If Operating Systems decide to tackle this problem at some point in the future, Firefox can always be changed again to use that.

2. Given that Firefox doesn't own the full market, the net result is indeed less centralisation: five ISPs that handle traffic by other browsers, and two DoH providers that handle Firefox's. That said, the main factor here is that the track record of ISPs in the US is abysmal, whereas the current (and hopefully potential future other ones) DoH providers have committed to far stronger privacy protections.

View on HN

For 1, you're spot on.

For 2, the one thing that's missing from here is that we _know_ many ISPs are selling your data. I'm really uncertain why people are so determined to villify Cloudflare - who don't really stand to gain that much more useful info about you from this than they already have - and give a totally clear pass to their ISP despite years of proven bad behaviour. Yeah this (by default) uses CF's DoH service - note that you can change this if you want - but in my view that's strictly better than continuing to allow your ISP to to sell your browsing history. In other words - a bit of by-default centralisation is in my view an acceptable price to pay for the increases in privacy and security (especially as it's trivial to switch away from CF if they behave badly).

A good solution would be to do DoH upgrade to their existing provider if the user already has DNS set to a non-ISP resolver (eg. Google, openDNS), only using CF as a default for ISP dns. That or racing multiple DoH providers for the first few queries to choose the fastest one for the user.

Internet gateways commonly give out the gateway's IP address as the DNS and then forward requests upstream from there. How does the application know which DNS the gateway is configured to use?

In [currently only] Chrome, it doesn't upgrade if the DNS advertised is the router. This proposed Firefox system then would default to CF [or default to the fastest one].

>who don't really stand to gain that much more useful info about you from this than they already have

that is absolutely untrue. Today they only have data for websites already using CloudFlare Services.

DoH they can info on ALL websites users for FF visit. and while their "contract" with mozilla requires they "anonymize" the data, they are admitted to collecting aggregate data which is VERY valuable in itself, plus I never trust companies when they say they will "anonymize" the data

Further I have not see what if any penalties are imposed on cloudfare for any violations of the "contract" they have with Mozilla, if there are no penalties then the contract is pointless and not an assurance of anything

As to why people villify Cloudflare, it is what CloudFlare represents that is a problem for people like me. The Internet is best serviced by decentralization. in the last 10 to 20 years we have seen and continue to see MASSIVE centralization of core infrastructure.

FF move here represents another step on that path. CloudFare already has too much of the net behind their infrastructure.

They are an inherit threat to the free and open web

FWIW, wrt 1: you can use dnscrypt and a bitbar plugin to have this at the OS level on Mac. It’s a faff to setup but once it works it really does work.

https://www.dnscrypt.org/

Optional for menu icon:

https://getbitbar.com/ and https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher

I think 1 is about OS defaults, not stuff users must know to do. People knowledgeable about privacy could always bolt things on, and that's quite orthogonal to this discussion. Rather, this is all about the people who do no installation/configuration beyond an OS and a browser.

https://www.dnscrypt.info

The .org is not legit.

So sorry, my bad. Mobile Google fail :( thanks for vetting !

> DoH providers have committed to far stronger privacy protections.

What about DNS tampering? In many countries there are different rules for taking down a website. My ISP applies different rules than 8.8.8.8, which is handy when required by law in France but not in USA.

Effectively, government-mandated tampering will be applied with much less granularity because of centralization (or bi-centralization).

In addition to (2), I imagine it's easier to set up a completing DoH service and get it included in Firefox than an ISP that can reach a similar number of users. So it may not always be so centralized.

The ISP can just check which IP you contact, so I don't see this increasing privacy.

And until ESNI gets high adoption they can also just look at the SNI header. I do not see how DoH gives any significant amount of extra privacy.

DoH doesn't need to provide extra privacy to make sense (although it is a mandatory stepping stone to good privacy). It also provides a difficult to block security upgrade (as opposed to DoT, which is easy to block).

We've seen regular US ISPs hijack unencrypted DNS to insert content or replace sites entirely. We've also seen bad actors do far worse on public WiFi.

So acting like DoH is a waste of time unless every part of the privacy puzzle is online is wrong-headed. It is a huge step in the right direction for privacy, increase their costs, and will be much needed when eSNI is online. In the meantime "all" we get is a huge security improvement.

Except, not really. If you're worried about DNS tampering, DNSSEC already exists all the way up to the root servers.

If you're worried about ISPs snooping on what sites you visit, they'll continue to be able to do this even with widespread DoH/DoT and ESNI adoption. You still need to connect to an IP and TLS certs still have unique serials (most of which appear on public CT logs). Correlated over a large user population, that's more than enough to get a pretty decent, aggregate view of what sites you're browsing (certainly enough to tailor ads/marketing towards you).

As for random third party networks (e.g. Starbucks wifi), if you're not using a VPN then I don't see what expectation of privacy/security you had in the first place.

Ultimately, if you don't trust your ISP (or whatever network you happen to be connected to), the only meaningful option is a VPN. Encrypting your DNS traffic to a resolver (whether with DoH or DoT) is, at best, a very incremental improvement in the arms race. It protects users against some of the most egregious ISP abuses (assuming said ISP doesn't also spoof the cert...) at the expense of potentially misleading them into thinking they have more privacy than they actually do. In the case of DoH it will also likely inadvertently end up centralising a huge chunk of DNS lookups in to the hands of a few large corporations thanks to it being opt-out rather than opt-in. At least DoT avoids that (and offers server-to-server encryption).

Much better for users who want unfettered internet access and privacy to encrypt the whole lot with a VPN and use a resolver that validates DNSSEC. If the chain of resolvers were all DoT enabled that would definitely be a nice extra but hardly essential.

Alternatively, if you're in a country with a healthy ISP market (and government you're not afraid of), there's always the option to simply move to a provider that doesn't tamper with and monetise user traffic.

> TLS certs still have unique serials

In TLS 1.3 everything sent by the server, including its certificate, is encrypted.

This is possible because of a re-ordering of considerations. It used to be that the conversation starts like this:

Client: "Hi, I want to talk to Server?"

Server: "Here's a certificate for Server, which is me"

Client: [ "Secret is 123456" encrypted using the Public Key from the certificate for Server ]

Server: [ "See, it's me" encrypted using the secret 123456 ]

But in TLS 1.3 it starts like this:

Client: "Hi, I want to talk to Server and I used ECDHE to pick this number 123"

Server: "I used ECDHE and I picked 456..." [ "I am Server, here's a Certificate for Server, and here's a signature proving the conversation we're having right now is with me, Server, which you can verify using the Public Key in that Certificate" encrypted using the secret 987654 ]

ECDHE allows Client and Server to agree the secret key 987654 even though the information they publish to agree on it (123 and 456) is public for anyone to see. Its predecessor Diffie Hellman is easier to understand if you never got past high school mathematics, so research that if you've never seen this trick before.

You'll notice this is also less round trips (so better performance over high latency links) as well as being more secure and more future-proof.

This is very cool. Thanks for the great explanation!

This is addressed in TFA: The fact that there are multiple problems and solving any one of them doesn't help much until they're all solved, should not be an excuse to refuse to solve any of them.

So you have a "solution" that doesn't really solve the problem, and also create a new privacy problem (now cloudflare has your data too). Hence it's actually a privacy loss.

For some (large, especially) sites, the IP address maps to the entity you're trying to contact. For others (small, especially) sites, the IP address is shared among many entities... not just shared origin hosts but also the massive reverse proxies of the world (Cloudflare, etc.).

There is an actual research on this. More than 90% of alexa's top 1 million websites (more like 95% or so) are uniquely identifiable just by IP addresses you connect to when you visit them. This is not a single IP address per website, but multiple, because websites include subresources with other IP addresses to connect to.

On top of that, there is a pressure on CDNs and clouds to make websites stick to specific IP addresses and make them blockable by IP addresses without affecting other customers. So far they have proven to not go against this pressure and even made technical solutions to aid governments to identify websites by IP addresses, in particular by fixing L7 routing layer to block domain fronting (which is important, because ESNI is basically domain fronting, but crappy, and the pressure didn't go anywhere, so there is the same pressure to make sure ESNI doesn't interfere with identification of websites you are visiting).

How would they force cloud providers customers to host on an ip? Do you envision restrictig new instances with manual approvals required?

Also, Cloudflare does give Business and Enterprise customers their own IP addresses (although often rotated) so that these sites work with old non-SNI browsers.

That doesn't work anymore. ISPs are not going to block AWS IP ranges or Azure IP ranges, etc. The cloud killed IP blocking. The pirate bay is supposed to be blocked in UK by court order, but because they use cloudflare it's still accessible and only DNS blocked.

> ISPs are not going to block AWS IP ranges or Azure IP ranges, etc.

Tell that to China, Iran, Turkey (?), etc.

Ok, authoritarian regimes not included

> Ok, authoritarian regimes not included

And yet this was/is one of the justifications for implementing this.

They're not doing it in the EU because (a) there are decent privacy laws, and (b) IP addresses are (IIRC) considered personal information and so Cloudflare DoH would be responsible for keep a whole bunch of data safe. They may not want that responsibility.

This seems to (currently) be US-only because of the sucky US privacy laws.

No the justification is to make it harder for non-authoritarian countries to block websites. If China or North Korea want to block the IP range of AWS+Azure+Google that's up to their respective autocrats.

Most democratic or even hybrid regimes are not prepared for that level of absolute chaos and consequent protest if half the Internet is shut down. You can only pull that shit in a dictatorship.

Blocking wasn't the point in the post above.

Okay fair but they are two sides of the same coin. Blocking is active snooping. If an ISP knows what site you are visiting they can block the connection. In both cases the way to prevent it is to extinguish privacy leaks.

In addition to 1) ideally the user can just choose here. Which the user currently sort of can, so I don't see a problem with it.

For point 1, Windows 10 plans to implement this.

Reply on news.ycombinator.com