Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

151–160 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#151

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…

The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades.

The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.

Re: Improving DNS Privacy with Oblivious DoH

#152

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…

Can't you do something analogous to editing your hosts file (but for name servers) and then re-centralize all of your apps using a single name server, which you can then control however you like?

Re: Improving DNS Privacy with Oblivious DoH

#153

Earlier quoted context omitted.

It is part of their marketing. The fact that others sell or actively use your data, e.g. google, facebook, microsoft, apple was handed the opportunity to charge a premium for the absence of such tracking and data usage. If you watch the presentations, they branded/poised themselves as the privacy centric approach.

I see your point about how they (will) position it, but I’m still curious about their actual motives.

As a preface, I am about to describe something I personally view as absolutely horrific. Please, dear reader, in no way interpret these comments as approving.

Privacy is a luxury. It's something rich people buy and poor people can't afford to concern themselves with. Apple sells a luxury product, and has no particular stake in invading customer privacy at the moment (iAd was never successful enough to change that). So they add a feature to their status symbol to address the concerns of their customer base and work with a partner company that can actually deploy it.

Re: Improving DNS Privacy with Oblivious DoH

#154

In a nutshell: client encrypts to proxy, which decrypts & removes client info, then asks resolver. > “What ODoH is meant to do is separate the information about who is making the query and what the query is,” said Nick Sullivan, Cloudflare’s head of research. > In other words, ODoH ensures that only the proxy knows the identity of the internet user and that the DNS resolver only knows the website being requested. Sul…

> client encrypts to proxy, which decrypts & removes client info

This is incorrect; the proxy doesn't decrypt. It just proxies. From https://blog.cloudflare.com/oblivious-dns/ :

> The target decrypts queries encrypted by the client, via a proxy. Similarly, the target encrypts responses and returns them to the proxy. [...] The proxy does as a proxy is supposed to do, in that it forwards messages between client and target.

Re: Improving DNS Privacy with Oblivious DoH

#155

Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare) [1] https://en.m.wikipedia.org/wiki/Server_Name_Indication

No! Solving the SNI problem is far from enough. The server IP address can be easily correlated with the domain for 90% of Internet traffic.

Do you have a citation for only 10% of internet traffic using CDNs? Even things like cloud load-balances and ephemeral IPs make those associations hard and we’re in third decade of major web properties using CDNs.

Re: Improving DNS Privacy with Oblivious DoH

#156

Earlier quoted context omitted.

For most of the software on my computer, the developer certificate is enough information to know what software I'm running. Are they going to think I'm running some other piece of software signed by Slack Inc.?

For most of the software on my computer, the developer certificate is enough information to know what software I'm running. All your ISP can see is certificate hashes , OCSP lookups and DNS queries. It can't know what certificate hash is connected to what developer application…

It's not hard to match up a certificate hash to the issuer, because most issuers will likely only have a couple of certificates to simplify internal PKI. It's something that can be solved with a rainbow table, there aren't even salts involved.

Re: Improving DNS Privacy with Oblivious DoH

#157
post #78

I suspect that practical matters will interfere with widespread adoption of encrypted DNS. In my state, Comcast is going to start charging heavy bandwidth users extra. After a few people get surprise bills, I suspect that lawmakers will require that internet providers break down a bill by application.

Mobile OSes already support per-application network usage breakdowns. This is an OS-level feature, and not an ISP-level feature.

Re: Improving DNS Privacy with Oblivious DoH

#158

Earlier quoted context omitted.

For most of the software on my computer, the developer certificate is enough information to know what software I'm running. Are they going to think I'm running some other piece of software signed by Slack Inc.?

For most of the software on my computer, the developer certificate is enough information to know what software I'm running. All your ISP can see is certificate hashes , OCSP lookups and DNS queries. It can't know what certificate hash is connected to what developer application…

Presumably that's an unsalted hash so that it can be checked against the list of certificate revocations, so whether it's a hash or not doesn't do anything for privacy. It's the same hash of Slack's dev certificate that every other Slack customer is sending.

Anyone snooping the connection can figure that out and see that my computer said "Check the revocation status of Slack Inc.," and the same goes for literally every other software company's certificate hash.

I'm glad it's being fixed but it's still bad that it was done this way in the first place.

Re: Improving DNS Privacy with Oblivious DoH

#159

Earlier quoted context omitted.

Part of the counter-argument that has been so prevalent on HN (most recently: [0]) is that when you prevent middlemen on your network from being able to see what website you're browsing, you're doing exactly that: preventing anyone, even a trusted network administrator, from being able to inspect traffic. I'm all for DoH and ECH since US ISPs have a history of inspecting and logging traffic, but it seems like there s…

Yeah, but that argument sounds like asking people to use “logmein” as a password so they don’t need to install MDM on everything. Management of devices without authentication and authorization means anyone can do it. Which is the state of things today (for DNS).

I think you've nailed the core of it.

Managing traffic over your network and the devices on your network are very similar tasks that aim to accomplish very similar things. However, they are not equivalent tasks. Relying on traffic management to accomplish device management eventually runs into conflicts. These may stem from unmanaged devices, guest devices, unmanageable devices, or the consequences of the total lack of authentication and authorization.

Ultimately, managing traffic and managing devices are not tasks that replace one another.

Re: Improving DNS Privacy with Oblivious DoH

#160

Earlier quoted context omitted.

As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising. Surel…

You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour. You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all. Traffic that is local to a network being unencrypted is not a huge privac…

Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.
Post reply on HN