Improving DNS Privacy with Oblivious DoH

Post by karmakaze » Wed, Dec 09, 2020, 1:54 AM UTC

nathcd wrote: post #154

karmakaze wrote: post #150

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 tar…

Post by mmis1000 » Wed, Dec 09, 2020, 1:59 AM UTC

josephcsible wrote: post #232

mmis1000 wrote: post #170

Earlier quoted context omitted.

The correct answer will be reverse, get rid of SNI completely and enforce ESNI everywhere. Most bad entity now only need to block ESNI, and then the client will happily fallback to plain SNI. If everyone enforce ESNI only, then it is not gonna going to work. Just like nowadays, a browser can't view https site is completely useless because most of sites on internet were already encrypted(and the percentage is only goi…

We don't need to kill regular SNI to fix that problem. If a site's DNS record indicates that it supports eSNI, and a connection with eSNI fails, then the browser should hard-fail. And middleboxes can't lie about whether a site supports eSNI, since that's protected by DNSSEC (and it should be coming over DoH anyway). This would break the bad actors without breaking every site that didn't upgrade to eSNI.

Post by pdonis » Wed, Dec 09, 2020, 2:37 AM UTC

fiddlerwoaroof wrote: post #167

acdha wrote: post #151

Earlier quoted context omitted.

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.

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.

Post by Lammy » Wed, Dec 09, 2020, 3:00 AM UTC

xg15 wrote: post #262

stevepike wrote: post #145

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…

If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either. To me, DoH seems less about protecting the user…

Post by rubyfan » Wed, Dec 09, 2020, 3:08 AM UTC

TrueDuality wrote: post #171

rubyfan wrote: post #161

Earlier quoted context omitted.

When enterprises own the devices on their networks they can add whatever root certificate they like and MITM filter whatever they like. This makes over the network traffic more secure and does nothing to really impact threat detection. If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.

Adding in root certificates and performing HTTPS MITM even on your own network is a huge risk on its own. You're basically breaking many layers of security such as certificate pinning that just get disabled with any custom root certificate. Those middleboxes will always break client certificate authentication and you're trusting that they are checking the various revocation lists they should be (CRL/OSCP/various buil…