Hacker News Reader

Comment by mschuster91 | Hacker News Reader

The problem is, there is no better approach to check for intercepting middleboxes. Using a well-known path (like gstatic.com/generate_204) works for detecting if the user has a captive portal between them and the Internet, but not if the user's provider messes around with DNS.

View on HN

> there is no better approach to check for intercepting middleboxes

I can see some purposes for detecting middleboxes. I've done it. It usually doesn't involve DNS. It does involve certificate pinning though.

> detecting if the user has a captive portal between them and the Internet

That's easy. Try to browse to something. If succeeds but the certificate isn't valid then the user probably has a captive portal. That, or your pinned certificate has been revoked.

> detecting ... if the user's provider messes around with DNS

Certificate pinning, again, comes to the rescue. Pin a certificate to your own DoH server and then use DoH to look up whatever you need.

If you can't connect to your DoH server then you effectively aren't (or shouldn't be) connected to the internet.

The kind of interception that is being discussed here is the interception of DNS queries which would return an NXDOMAIN result to instead point to an advertising page. This is done by a lot of ISPs.

It is an interesting tricky problem. As the DNS system was designed for caching and an 'honor system'. How do you allow caching so you do not completely overwhelm the root servers yet still prevent modification/interception of the contents of the messages? DoH sort of addresses it. But then you still have to trust that the message has not been altered/intercepted at the DoH server. Yet we also want the server to be able to do a replay of that message to another client. Also how to retrofit all of the existing code that uses DNS that uses this magic system. It is like we need a lightweight one way TLS session but with certificate caching and a second request/response type with a hash. But you have to watch out for cert forging then.

That the browsers are reacting in this way says we have a failure at the DNS software level. Those projects do seem to be giving the security that is wanted. So we are starting to get some fragmentation. Which can not be good. Perhaps we need new record types to support this?

> Perhaps we need new record types to support this?

The solution would have been DNSSEC, the problem is that authenticating NXDOMAIN responses comes with a ton of challenges on its own and so there, in the end, was just workarounds and messy hacks [1] that IIRC no one ended up utilizing.

[1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...

No, it's not! The problem here is end-users being forced to trust their upstream DNS caches. DNSSEC doesn't change that! It's a server-to-server protocol, so the same NXDOMAIN interception problem exists --- the intercepting DNS server just sets the AD bit in the header. You can run DNSSEC directly from an end-system, bypassing caches --- but then, relieving load on the roots (a non-issue, but still) is right out the window.

You are right. My brain decided to forget that existed!

We are nowhere even in the perceptible range of "completely overwhelming" the root servers.

the middlebox could just pass traffic for the unknown TLDs tho and that detectin method would be in vain

Google could host their own DNS servers who only give out NXD and test against that.

As soon as Google would do that, providers would implement exceptions.

They could do DPI, allow traffic for unknown domains, intercept everything else. Differentiating random domain from "what user might actually type by accident" is also pretty trivial

Reply on news.ycombinator.com