Hacker News new | past | comments | ask | show | jobs | submit login

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!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: