5 ms·

(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course) Thanks for posting this. I knew Paul is against DoH, but never understo

• zzzcpan 8y ago
  Your ISP doesn't really need DNS traffic to know things about you, IP addresses alone leak a lot of information, add to that SNI, response sizes, active probing, clear text traffic, etc. and you should realize that the only thing DoH does is letting one extra party to know what you are doing in addition to your ISP. DoH is net negative for privacy. You need at least a VPN to get to net positive, so that your ISP can't get that much data.
  • wbl 8y ago
    How is DoH a net negative? ESNI is coming soon. Also ISPs do all sorts of other badness with DNS like NXDOMAIN interception.
    • zzzcpan 8y ago
      If you can't trust your ISP, leaking all of your DNS traffic to another party still doesn't let you trust your ISP, but now you have to trust that other party too, hence net negative. To avoid trusting your ISP you need at least a VPN.
      • judge2020 8y ago
        ISPs already don't have a good track record, so I would argue them NXDOMAIN advertising (like Spectrum does by redirecting you to a yahoo search page) won't make someone unsubscribe from their services. But if a service like 1^4, that specifically states they don't track you, lies about it, then that would be a huge issue for all of the customers that pay for the company's other products.
      • wbl 8y ago
        Now that I use another revolver the NXDOMAIN problem is fixed.
  • sroussey 8y ago
    SNI is getting encrypted soon too
    • zzzcpan 8y ago
      Within next 10 years maybe. It doesn't solve anything though and is plenty of time for DPI vendors to pursue other snooping techniques.
    • the8472 8y ago
      Only if you go through big, centralized cloud providers fronting the traffic. You're just replacing your ISP with the the CDN.
      • Spivak 8y ago
        The person who wrote your application stood it up using that CDN though. There are two parties we're concerned about: you and the entity you're communicating with. You trust your device and the entity, and the entity trusts the infrastructure and services they're using. Everything else is the enemy. So moving the barrier to a CDN which the entity trusts is actually an improvement over intermediate ISPs which neither of you trust.
        • the8472 8y ago
          They may simply not care and only "trust" the CDN in so far as it bypasses local resolvers. I.e. they might be using it for reasons not aligned with my interests and not vet the CDN at all.
• nykolasz 8y ago
  I work at a k12 school and I am involved with many IT admins from other schools. Some schools already started to block Firefox from being installed because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line between your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content. Unfortunately, on our school network, we also allow BYOD, so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.
  • Spivak 8y ago
    Look I sympathize with all the k12 network operators that have to apply all these brain-dead content filtering policies -- I used to be one. But surely you recognize that someone external to my device that can inspect, modify, compromise the security of, or block my connection to any part of the public internet is the enemy right? You're free to do whatever you like with devices that you own and you're also free to have an acceptable use policy on your network but breaking security and privacy to accomplish it is the exact wrong way to go about it. In my ideal world school BYOD devices would either not be allowed at or be given a private single-device VLAN with a direct unfiltered connection upstream, and made clear in policy that the school doesn't own, support, or control any aspect of them. No different whatsoever than students using their cellular connection.
• femiagbabiaka 8y ago
  > Many DNS people are opposed DoH, but I think this train has passed. That’s not a very good governance strategy.
• stirfrykitty 8y ago
  Why not run a Pi-hole? You only stand to benefit. Whilst it doesn't address DoH, it does go a long way in preventing the tracking you mention. It also saves on bandwidth. And because it works at the DNS level, you benefit from the calls not even being made. The Pi-hole can be customized with an endless set of rules to block about any ads, beacons, trackers. Couple this with uBlock Origin, Privacy Badger, Decentraleys, Referer Block, and some creative browser settings (about:config) and you are largely safe from prying eyes. JS can be whitelisted, etc. You have nothing to lose.
  • Nas808 8y ago
    You can do both, I have a Pi-Hole running alongside the “Cloudflared” package so Dnsmasq forwards lookups to Cloudflare over DoH.
    • KitDuncan 8y ago
      My setup is similar. Pihole with dnssec and dnscrypt-proxy connected to cloudflare. Didn't see a reason to use the cloudflared package instead of dnscrypt-proxy.
• aepiepaey 8y ago
  > I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party. Not true. They may be connecting directly by IP (it's typically not possible to determine if they did just from access logs). The web (or other application) server may also leak the name when connected to. If you use TLS, which is likely, your domain names would leak through the certificate transparency logs. ...and there are surely more leak vectors than the above, so it's far from certain that the crawlers you see found their target by sniffing your DNS requests.
• the8472 8y ago
  If you don't trust your network why don't you install a DNS stub resolver that tunnels to some external resolver that you trust and then set the OS to use localhost? Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.
  • Spivak 8y ago
    > install a DNS stub resolver that tunnels to some external resolver that you trust. Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.
    • the8472 8y ago
      You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them. As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver. OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic
      • Spivak 8y ago
        Browsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP. I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.
        • the8472 8y ago
          I don't think this is the proper approach. Once it's in browsers it will also be in electron applications. And those may update less frequently. Now you have balkanized implementations of custom DNS stub resolvers using different remote endpoints. That makes security updates more difficult, network issues more difficult to debug and so on. Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.
• mook 8y ago
  I'm mostly like you, except I've seen where DoH (or rather the equivalent DNS control) can go wrong on my local network. I have a NAS, and did not set up the manufacturer's optional global DNS routing (because why the heck should anything on the internet know anything about my NAS). Unfortunately that means my Chromecast doesn't stream files off it properly, because that hard codes to using Google's global DNS servers (8.8.8.8), which isn't going to know about my local hostnames (nas.lan). I've had to change things to use IP addresses instead.
• xorcist 8y ago
  > The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party. There are a number of other, perhaps more likely, reasons your hostnames have leaked. Have you got any certificates for any of those names? Then they are in the public CT database which numerous people constantly scan for interesting data. Are any of your DNS zones enumerable for some reason? Same thing. Any reverse DNS set up? What protocols and public services do you run? Do any expose hostnames in the protocol handshake? Then you are in the public Internet scan datasets. As soon as you run any kind of SSL on any of your protocols your hostname is in the SNI header. Host names are visible in a number of ways. It is best to consider them public data. I have seen a number of ISPs from the inside, and none of them has had any interesting in wiretapping their customer's DNS data. I'm not saying it doesn't happen, but it can't be very common. They have much more interesting data available to them should they want to go down that road.
  • phyzome 8y ago
    One way to test this would be to have the browser pointed to a page on a wildcard subdomain, and have a port 80 non-SSL listener logging requests.
• JohnFen 8y ago
  > Personally I'm not an "owner" of the networks I'm connecting to. But I am the owner of my own network, and DoH reduces my ability to protect it. That is the main (but not only) reason why I strongly object to DoH. > I think this train has passed. I suspect the battle has just begun. For example, my response to DoH has been to implement a MITM packet inspection system on my network to regain control over this. This means that DoH will not work from my network. I expect that we're going to see this sort of thing more and more.
  • comex 8y ago
    What exactly are the threats that you expect blocking DoH to protect you from? If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it, rather than trying to prevent them from learning where it is?
    • JohnFen 8y ago
      > What exactly are the threats that you expect blocking DoH to protect you from? I want to maintain the ability to block the resolution of certain domain names. The threat model is malicious software or websites that want to phone home. This includes reaching out to command-and-control servers, ad tracking servers, data exfiltration points, etc. > If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it Because most of the malicious actors don't use raw IP addresses as they can change frequently and without notice. They resolve a domain name instead. Blocking the domain name lookup is therefor more effective and less likely to result in blocking the wrong things than working with raw IP addresses. This is not a replacement for other security measures (including IP-based blocks), but is is, in my opinion, a critical measure in and of itself.