Live data from Hacker News

Improving DNS Privacy in Firefox

blog.nightly.mozilla.org

41–50 of 126 posts

Re: Improving DNS Privacy in Firefox

#41
post #33
post #7

Earlier quoted context omitted.

They are completely independent protocols, with their own issues in this area. For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view. Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how…

They cannot be independent if actual privacy is concerned. At least sharing a threat model that touches both layers.

They are mostly independent. Your privacy loss is by and large the sum (or max) of the privacy loss caused by DNS and TLS individually.

For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare.

For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers.

At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.

Re: Improving DNS Privacy in Firefox

#42
post #4

There seems to be little point of doing this, in my opinion, when SNI doesn't secure the hostname.

SNI doesn't encrypt the hostname but in TLS 1.3 it does secure it against middleboxes. If a MitM tries to alter the SNI then the connection fails. TLS 1.3 also encrypts the server certificate. So if you want to send bonus SNI but get back real certificates that's just a matter between client and server. The use case for Encrypted SNI remains sketchy. If I am the secret police of some authoritarian nation, who would b…

> Only because it causes collateral damage? But why do I care

Because the collateral damage may not be worth it. The website a handful of dissidents use may not be worth blocking everything running on Cloudflare for all your citizens, for instance.

Re: Improving DNS Privacy in Firefox

#43
post #40

Earlier quoted context omitted.

Because at the moment, no major OS supports it.

dnscrypt-proxy ( https://github.com/jedisct1/dnscrypt-proxy ) supports all major platforms and checkout https://dnscrypt.info for more options.

It's worth noting that this is from the principle developer of libsodium as well.

Re: Improving DNS Privacy in Firefox

#44
post #5
post #4

There seems to be little point of doing this, in my opinion, when SNI doesn't secure the hostname.

Agreed, SNI and DNS need to be fixed together, not separately. And definitely without centralized services, like Cloudflare. Otherwise why not just go all the way with centralization and provide secure proxy for everyone in the browser.

Ironically, some amount of centralisation can improve privacy. Security is about confusion and diffusion; to get lost in a crowd you need to not be differentiated, and to not be the whole crowd. Encrypted SNI would mean ISPs could tell you were contacting Cloudflare servers, but not which of the many hosted websites you were requesting (assuming you also plug the DNS privacy gap too).

Re: Improving DNS Privacy in Firefox

#45
post #38

Earlier quoted context omitted.

I, too, have a local caching resolver. And I'm unlikely to turn this on at the browser level, although I'm occasionally tempted to play with it in the resolver. But I strongly suspect we're in the minority and that something like this is the easiest -- and quite possibly the only -- way for many users to avoid DNS poisoning by ISPs.

Not just ISPs; those using DNS-based adblockers (pi-hole and the like) will be impacted too (from my understanding.)

You're right.

Re: Improving DNS Privacy in Firefox

#46
post #38

Earlier quoted context omitted.

I, too, have a local caching resolver. And I'm unlikely to turn this on at the browser level, although I'm occasionally tempted to play with it in the resolver. But I strongly suspect we're in the minority and that something like this is the easiest -- and quite possibly the only -- way for many users to avoid DNS poisoning by ISPs.

Not just ISPs; those using DNS-based adblockers (pi-hole and the like) will be impacted too (from my understanding.)

I think you missed the point of the parent comment, it wasn't that only ISPs poisoning DNS are impacted it was that this solves that problem for the vast majority who have no clue, excepting those who do the exact thing you describe and understand how to point it at their pi-hole.

Re: Improving DNS Privacy in Firefox

#47

Core internet protocols like DNS over HTTP? Yet another step closer to HTTP/IP, I guess. Can’t say I condone it.

I think the main reason this happens is because SSL is a pain to configure and develop and it's easier to just use HTTP's SSL than to make an SSL version of everything else.

It wouldn't be my first choice for a lot of reasons, but HTTP2 is getting pretty close to just being a binary protocol anyways.

Re: Improving DNS Privacy in Firefox

#49

Core internet protocols like DNS over HTTP? Yet another step closer to HTTP/IP, I guess. Can’t say I condone it.

I think the main reason this happens is because SSL is a pain to configure and develop and it's easier to just use HTTP's SSL than to make an SSL version of everything else. It wouldn't be my first choice for a lot of reasons, but HTTP2 is getting pretty close to just being a binary protocol anyways.

DNS over TLS is RFC 7858. It already exists.

Re: Improving DNS Privacy in Firefox

#50
post #24

Why would I want my browser to do this? My browser should use the DNS configured by my OS -- in my case, a local, caching resolving NS. If I want to use some kind of DNS-over-HTTP I'll tell my OS to do it. I don't want my browser making DNS decisions for me. What am I missing?

You're missing that you're a technically skilled individual, and most browser users are not. The design decisions must cater to the unskilled, because they will not opt in manually. By default most OSes will use their ISP's DNS, and this will very often be insecure and compromised in some way.
Post reply on HN