With 90% of their money coming from Google for decades they can’t bite the hand that feed them. The question is why Google is keeping them afloat? My guess is that a few millions here and there to create the illusion of competition is way cheaper than having a monopoly investigation.
This is why I love Cloudflare. Makes everything secure and faster... for free (not to mention how easy it is to make records and go into developer mode to purge caching for a bit)
Have you asked yourself how they can make everything free? What are their incentives? When they successfully centralized majority of DNS resolving, what could they do with that power? Keep in mind that even if their motives are pure at the moment, management and ownership of companies can change.
Look a few years back and you’ll find similar enthusiastic comments about Google: they make everything better and for free. Everyone should use their search, everyone should move to GMail, etc.
Good points. As others have said, I'll probably move off later on, but for now I intend to stay with them (similarly I've been with Gmail for a while and now moved off to stuff like Fastmail, hosting my own "dropbox", etc.).
Primarily because for beginners it's a bit easier to setup everything without much hassle.
I think it was certbot that was recommended by DO to use; I used certbot and it was super easy to setup, but at the moment I feel that Cloudflare's security, fast delivery, and analytics will keep me onboard until I can self host/do myself when I have a good amount of time.
Good point. I think they crossed a line when they shut down controversial sites, which they shouldn't have, but at the same time it's easier for beginners to start out with everything.
DNS over HTTPS feels to me like we're edging towards end-to-end encryption for DNS. This seems like a good thing, but even though it will protect against ISP and state level observations of DNS, will it not reduce ones control over DNS locally?
My threat model remains web site operators and the malware and tracking inserted at that point. Additionally devices on the network that may observe locally and communicate externally like TV boxes and games consoles.
To manage those threats I use Pi-Hole. But once we start end-to-end encrypting, and especially when we start verifying those ends, how do I locally intercept and manage DNS for my privacy and security?
Is this a genuine concern about DNS over HTTPS? Or is the plan to enable systems like Pi-Hole to be a trusted and configurable resolver too so that consumers retain the ability to control their own systems like this?
You just have to make your Pi Hole a proxy. You configure your OS/Firefox to connect to the pi for dns and the pi makes the request for the dns record.
All this assumes though that the devices can be configured to do that. While that's likely for browsers, it's less likely for smart TVs or other IoT devices, especially if you don't trust the devices in the first place.
(Edit: removed bit about root CA certs because I misunderstood)
if the certificates are pinned, you're screwed. Even if they aren't, it's a matter of luck if your smart$thing accepts self-signed certificates for $thingsdomain.
> it will protect against ISP and state level observations of DNS
It won't if it defaults to centralized on-profit business like Cloudflare. They can tap for govts or sell aggregated data to ISPs someday. They aready own a lot of unencrypted traffic from TLS-termination.
Wouldn't it be better to use public/private key signing and onion-like infrastructure for DNS resolving and still keep it distributed?
> will it not reduce ones control over DNS locally
No. Run your own DoH server, point your DoH client to your own DoH server, and your DoH server can then provide any responses you want. (And it in turn can use DoH or do standard recursive resolution.)
End-to-end encryption means that malicious parties can't MITM your traffic or otherwise make you talk to the wrong destination server. That doesn't prevent you from intentionally running your own local servers and pointing clients to them.
If you have a client device on your network that you don't trust and can't change the configuration of, it has far more secure methods for protecting itself from you than just using DoH.
I think the last line is the major concern for the OP. It's fine and dandy if your browser _lets_ you use different DOH server with it's own self-signed cert. If you're locked down... well, it's game over.
No reason you can't get a real certificate, to ensure that your device talks to the server it intends to.
> If you're locked down... well, it's game over.
Devices today can already use pinned certificates and other similar measures to ensure that they only talk to the server they want to talk to. DoH doesn't make that any more or less effective, just simpler to get right.
A trusted certificate is nice and all but if you have to rely on DNS to find the CNAME-record that translates to an A-record and so forth, it becomes complicated and simpler for malicious parties to MITM you. A self signed certificate is actually better in that sense that nothing trusts it and with the assumption that you can add permanent exceptions and pinning, you'll know immediately if something is wrong.
> No reason you can't get a real certificate, to ensure that your device talks to the server it intends to.
You'd have to get a certificate for whatever domain the device wants to talk to - a domain you very likely have no control over.
No sane CA will give you a cert for that. The whole point of the PKI is to keep MITMs from pretending to be domains that they actually don't control - which is exactly what we'd be doing here.
The intent would be that the device has a setting where you pick which DoH service to use, and if that's a free text input you can put my-doh-server.my-vanity-domain.example
If 90% of users leave it as shipped set to (say) Google, 9% switch to their preferred service and only a handful like you actually type in a DNS name, that freedom to do is preserved. If it doesn't check the certificate from the DoH server when you override the configuration, you are immediately exposed to a MITM so it needs to check. However you'll have no trouble getting a cert for your own FQDN, and that's what the poster you replied to is thinking of.
Not all devices have a screen or an easy method to input a TRR URL. So even if a vendor has the best intentions, the effort needed to make DoH configurable could be more than what can be justified for a "niche feature".
I believe there are ideas for a network-level autodiscovery of DoH servers, analogous to regular DNS. That would solve the problem, but I can't see how it would get buy-in from the DoH crowd, as it would tie DNS to the network again - and it would still have to be implemented by every single device.
Of course all of this is moot if the vendor actively wants to prevent you from intercepting DNS.
> No. Run your own DoH server, point your DoH client to your own DoH server ...
Except when the client ignores what you tell it. Per Paul Vixie:
google, this is bogus as hell. my dhcp server gives you dns servers to
use. please don't make me route and answer 8.8.8.8 just to watch youtube.
> [71] 2019-02-13 16:39:40.548137 [#68 vtnet0 4095] \
> [24.104.150.186].56915 [8.8.8.8].53 \
> dns QUERY,NOERROR,7357,rd \
> 1 lh3.googleusercontent.com,IN,A 0 0 0
> [71] 2019-02-13 16:39:40.548210 [#69 vtnet0 4095] \
> [24.104.150.186].56915 [8.8.8.8].53 \
> dns QUERY,NOERROR,49247,rd \
> 1 lh3.googleusercontent.com,IN,AAAA 0 0 0
(no, this device i've paid for, will NOT be allowed to send you any
information, other than what i personally approve, which will never
include DNS traffic. if you don't like that deal, buy it back from me
and i'll find some other video appliance that doesn't twist my arm.)
I've been on networks where everything had to go through a proxy, where browsers were told how to act via WPAD/proxy.pac and you set an HTTPS_PROXY env for wget/cURL to work.
The goal isn’t adding privacy on enterprise networks. Enterprise networks should already be accounting for the existence of HTTPS, and either allowing, blocking, or proxying employee/device connections based on their threat model.
The goal for DoH is to improve privacy for individual humans, and it does that.
I mean, the actual solution here is... don't buy devices that refuse to do what you tell them. Don't use closed-source, auto-updating software. You can live without a Chromecast and a Amazon Echo and your cloud-based smart lighting system. There's alternatives to all these things anyway, which do what you tell them to.
Malware can do whatever it wants anyway - DNS-over-whatever can be implemented no matter who supports it. Maybe we should be banning Tor because it might be used by malware?
Tor has its own traffic signature and so can be detected by network monitoring software. If it's on the IT network I help run then I'm tracking down the source IP and MAC and finding the network port it's coming from and asking "WTF?".
I'm happy to implement DoT on work's network to help encourage encrypted DNS. My problem is DoH can now be used by all sorts garbage and we can't tell it from legitimate HTTPS--which is by design.
All this for the laudable goal of protecting Internet surfers' privacy. However I'm curious to know how well this will work against the Great Firewall of China, and how many other regimes will now implement Great Firewalls of their own.
Tor has bridges, which are specifically designed to thwart the Great Firewall - and I'm guessing your network monitoring software.
Malware can ship with an arbitrary number of DNS-over-HTTPS servers accessible anyway, no matter whether Google supports it. The cat was out of the bag as soon as you allowed encryption on your network in general.
Finally, there are system architectures that are inherently less susceptible to malware, which is what we should really be focusing on. If your document viewer doesn't need to access the Internet, why does it have access to the Internet? Why does your general-web-browsing browser have access to your intranet and worse, your network drives and USB sticks? The reason we're stuck with what we have now is that operating systems research largely died in the 90s, but we're now aware that e.g. microkernel capability systems can be implemented in ways that are both fast and secure.
Tor also gives you the option to use a variety of pluggable transports, which are purpose-built to circumvent DPI boxes and such. Pretty sure obfs4 (based on [1]) works against the GFW.
If you can't trust your device, you can't trust it without DoH either. As I said upthread, devices don't even need to use DNS. They can open up encrypted C&C channels, using whatever protocol they'd like, tunneled over whatever they'd like. They can bake rendezvous IP addresses in, they can cryptographically verify endpoints to break MITM proxies, they can even sneak data out in ICMP packets. DoH has literally nothing to do with it.
What's insidious about this argument is that it preys on peoples legitimate concerns about uncontrolled devices on their network. We're all concerned about that! But that doesn't mean we should use plaintext DNS, or Paul Vixie's preferred "encrypted DNS with a killswitch for network operators".
There are instructions[1] for pointing your Pi-Hole directly to Cloudflare to forward DNS requests over DoH. You can use the same software to point at any other DoH resolver, and you can disable (or alter the endpoint for) the DoH resolvers in Firefox and Chrome.
In July of this year my ISP (Entel Chile) started blocking all ICMP and DNS to non-Entel resolvers. They will not respond to tickets requesting an explanation or confirmation - DNS and ICMP just went dark. In response, I set up DoH on my Pi-Hole with the instructions above.
I don't trust Cloudflare, so a couple weeks ago I started modifying the tools from doh-proxy [2] to run in a container [3]. I have this running in three locations under my control, in networks that I trust (or at least that I trust more than Cloudflare), and in one location I run a proxy that uses Nginx to load-balance requests across the multiple locations.
I made two videos that show how you can set this up, first about the proxy [4] and how to run a stub DNS-to-DoH forwarder in Docker on your local machine if you don't control the network DNS server, and then about how to set up your own private DoH resolvers in Kubernetes (using a $5 VPS and running k3s) [5].
These solutions, while more technical than what my mom can put together, will not only use systems that you control, but depending on how you set it up, will encrypt all DNS traffic from your machine. Encrypting browser traffic is good for the masses, but it only solves a small part of the problem.
Even if you only use the proxy, you can forward to public DoH resolvers that include parental filters, adblocking, and other benefits. If you don't have a Pi-Hole or can't run one, you can get the same benefits with a service like NextDNS [6], who have a generous free tier.
The next step is to configure the resolver to support auth, so that it's not all just hanging out on the Internet like it is at the moment.
For those who are asking about malware and if DoH makes it easier - consider that this is an HTTPS request. All any malware has to do (and already does) is bypass your system's DNS configuration and make the HTTPS request for DNS resolution of C2 systems directly. Whether or not you have DoH active on your system for other requests is irrelevant.
Device manufacturers will absolutely use DoH (with a pinned certificate) as an architecture of control. You won't be able to filter network access for such devices. They'll just fail to work if you attempt to intercept their traffic. DoH is a gift for device manufacturers who want to ensure forced obsolescence, make sure their ads get displayed, etc.
Devices already use pinned certificates, but DoH gives the device manufacturer a convenient and unblockabke way to resolve names against a trusted server. Device manufacturers could be jerks already, but I'd argue that DoH lowers the barrier-to-entry for being a jerk.
Consumers don't, by and large, give a damn about whether they actually own their devices or not. This is yet another reason why those of us who care about ownership and control of our own networks can't have the cool new "toys". We're back to feudalism.
Chromecast for example forces it's device to bypass local resolution and use Google's DNS. Bad Google, but that would still be an issue even without DoH. With DoH you just won't be able to port block ":53" which no one really does anyway. If you want device manufacturers to behave you're going to have to do it through regulation.
Device manufacturers don't need DoH to implement an architecture of control. They already have everything they need to do so. They don't even need to use DNS at all.
I should have said "yet another architecture of control".
Call it the opposite of defense-in-depth. Device manufacturers who aren't thorough might allow a class of "attacks" by way of using DNS. Having ubiquitous DoH takes away that "attack" vector.
I'm not arguing device manufacturers need DoH to be jerks. Having it available just enables the less sophisticated ones to be jerky more easily. DNS-over-TLS does the same thing, it's just marginally less frustrating because it can be blocked at the network layer, at least.
I understand that allowing owners of devices to do what they want on their own networks runs counter to the whole "protect the public from bad network operators" / "protect the public from bad people" narrative. I'm in the minority. It's just damned frustrating. It's sucking all the fun out of computing and networking. It's irrational and self-serving, but dammit it makes me angry.
This doesn't make any sense. Device vendors don't need encrypted DNS to obfuscate their command-and-control any more than bot developers do. They already have code execution on their platform that has network access. They can use whatever encrypted channel they want. Skype was doing this before DoH had even occurred to anybody. We're supposed to tell home users to keep using plaintext DNS because an incompetent device manufacturer might not be able to come up with a better encrypted C&C than DoH?
I'm not arguing home users, or anybody, should keep using unencrypted DNS. I'm not arguing anything. I'm just depressed as hell that every solution to "protect the average person" involves making me own my devices even less. You're right, I'm wrong. I'm sorry I engaged. Chalk it up to me being old and angry.
I don't object to you being angry about devices you don't control on your home network. You should be angry about that. It just doesn't have anything to do with DNS.
You see, one thing is one or two vendors misusing protocols to remove users control from their devices. Another thing is an official protocol that does the same thing. We find have anywhere to run anymore.
As bi dollar corporations and organizations are more and more "protecting" ourselves they need to remove control from ourselves.
As a counterpoint, it feels like you're complaining about losing the ability to control a device you don't normally have the ability to control by exploiting some facet of it's operation.
Isn't the real problem that you don't control the device in the first place? Perhaps the better solution is to only run devices and software that you can actually trust, if the security of those devices is important to you, or if you care about the device's behavior.
Firefox could make a long-need replacement for DNS, but they chose to spend all this effort on adding more ducktape to the current system, while also contributing to its centralization (more control to Cloduflare, yay).
DNS was a passable solution in the 80s, but right now it's absolute shit.
I don't really understand what kind of improvement is the DNS over HTTPS.
Yes some middle parties won't be able to tamper with my DNS queries. At what price? Total control for the people providing the DOH endpoints.
So chrome for sure will be using Google DNS for this, and with their efforts to remove ad blocking this fits nicely that you won't be able to use simply DNS based blocker.
We already have this situation though - the people who control DNS resolvers already have total control. ISPs have already been known to abuse this power [0].
This proposal doesn't solve this problem. Rather, it solves the problem of e.g. your ISP intercepting, logging and/or modifying your DNS request.
The solution will then just be to run your own DoH endpoint / proxy.
My first question in running my own DOH proxy will be how it works in my home network?
Right now I have my own dns configuration on my router, and any device that connects to the router is automatically using this dns. With DOH this doesn't seem to be the case though. I'll need to go and change the settings for each device to use my own DOH proxy. But whether I'll be allowed to do so is quite unclear if you ask me.
Becauae what happens when chrome says : "we have you covered, it's best to use only our DNS over HTTPS. If you need something else you can buy enterprise subscription"
Are you worried about things like Chrome fucking you over or are you worried about DNS encryption? The former does not require the latter, it's just one of a million ways to do it. Probably one of the more roundabout ways to be honest.
I don't know of any such reason. But I look at this from another angle.
This could have been DNS over TLS, or any other form of encryption. But it is DNS over HTTPS. This makes sense only for a browser, because they have the https stack already. But if we are talking about libc, it's very different story, there is no Http, let alone HTTPS there.
Over the year of discussions in regard to DNS over HTTPS I find the best illustration is to look at email. Your email client on the phone or PC send to a email over SMTP to a email server, the server look at the address and contact the recipient server and delivers the request. In email it is client->MTA->server-recipient. In DNS it is client->Resolver->Authoritive-server with the answer traveling back in the chain.
A little historical similarity, ISP used to provide a default MTA servers just like they do with resolver. Now days it most people use a email provider of choice.
So lets now imagine we solved the plain text problem of email by having the client use a default list of trusted MTA, with thunderbird defaulting to partner with gmail, and just sent it there over HTTPS. Gmail would take the email and forward it in plaintext to the recipient-server.
Email security did not follow that path. There we collectively decided to first encrypt communication between the client and the MTA using TLS, addressing the first step in the chain. Then the communication between MTA and recipient server got encrypted. In order to prevent downgrade attacks there is also currently two competing standards, one based on DNS and the other on HTTPS side channel. Looking at email, we are also almost done converting the plain text protocol to encrypted: https://transparencyreport.google.com/safer-email/overview
The general question is then, why not just copy the success of email? The answer it seem is about money. No company got more users or data when email protocols got encrypted. Cloudflare however will benefit if everyone route their DNS through them as that gives them a comparable performance benefit when people use them as a hosting provider. They also say they won't sell data, but people who move their domain hosting to cloudflare and pay for Pro, Business and Enterprise plan can get access to DNS analytics.
It was never brought forward for standardization and quickly got replaced by protocols that were. While it used UDP or TCP 443 it was a custom protocol so clients had to implement it manually and you couldn't run an HTTPS server on the same port (without modifying the HTTPS server/load balancer). It also relied on a separate certificate infrastructure.
Shortly after DoT and DoH came along as standardized proposals with fewer NIH issues and more interoperability. DoH also has the bonus of looking like standard HTTPS traffic to the resolver. Technically e.g. Google could host DoH on google.com/dns-query and it would be hidden in the deluge of HTTPS that already goes to google.com.
Still here, still what most public secure DNS run, still secure and reliable, still being constantly improved, and new implementations keep being written.
The protocol was recently extended with Anonymized DNS, a mechanism that hides client IP addresses from resolvers by using relays dedicated to secure DNS forwarding. A new network of DNS relays is currently being deployed.
DoH, DNSCrypt and DNS relaying can happily share the same TCP port 443.
A complete protocol description has been available for years, but turning it into an IETF document is time consuming. It will eventually happen, but as an independent project, writing software has been prioritized over marketing.
I wouldn't really call what happened to email a success. In reality, email these days looks much like your first scenario. Email is GMail and a few other large sites. Everybody else is a rounding error in statistics. For all intents and purposes these guys decide who can use email.
Yes, they don't use a simple trusted list, but some secret Algorithm. The effect is the same (or maybe it's worse, since if the Algorithm doesn't like you, there's no one to ask to add you to the list).
The security improvements you mention were more or less pushed onto others by Google and everybody was forced to implement them since if you can't talk to GMail you might as well as not exist in the SMTP world.
> No company got more users or data when email protocols got encrypted
This is speculation, but it's easy to see how these changes could have benefited big players: they already have the data. By forcing encryption on everyone they deny this information to others (like ISPs who might sniff the traffic).
Also these security improvements increase the burden of maintenance of small mail servers, which again pushes more users towards big players.
I'm not saying encrypting SMTP traffic didn't benefit the users, but reasons for forcing it on everyone might not have been completely altruistic.
Gmail is when I look around for market statitics around 30-40%. Second largest is Microsoft. Third Yahoo at something blow 15% with "other" trailing a few % below that. In the corporate space Microsoft is largest with office 365. G suit is common, but as I read it about half the market share of Office.
So no, not a rounding error and gmail is definitive not Email nor even 50% of it. Discussing market share also seems to me as very much the wrong question. Why should we not use the same process that email did when the world converted over to using encrypted email between client->MTA->Recipient? Is there a technical argument why converting things to HTTPS and then giving everything to whomever the browsers is partnered with is a better model?
One of the big concerns here is that this is another instance of "making the internet less decentralized by leaning on Cloudflare."
Someone once pointed out that if the NSA wanted to build a front company whose goal was to make hoovering up the internet easier, it would probably look a lot like Cloudflare. I'm generally not much of a conspiracy theorist, but this one has been frustratingly difficult to shrug off.
It can be less conspiratorial than that. It is a legal and diplomatic challenge for the US to get permission or to install infrastructure to monitor traffic in foreign countries. It is much easier for Cloudflare to drop an ingress server there, and they decrypt all TLS traffic that lands on their systems before possibly re-encrypting it and forwarding it over their private network.
Cloudflare is a US company and subject to US coercion. It would be trivial for the US to force Cloudflare to give them access to that data, and with Cloudflare currently decrypting ~10% of all Internet traffic, why wouldn't they?
How about the fact that Cloudflare-issued certificates are for dozens of domains? If the US wants to snoop on foreign domain X, a US order for US domain Y, also on the same cert, would give them the private key.
It's not possible to detect abuse in this system. It requires that we trust the state to not abuse their power, and we've seen them lie about that already.
The mere fact that the Cloudflare system _can_ be abused is, in my opinion, enough reason to go nowhere near it for anything.
> How about the fact that Cloudflare-issued certificates are for dozens of domains? If the US wants to snoop on foreign domain X, a US order for US domain Y, also on the same cert, would give them the private key.
Caveat 1 is that they've started to issue 1 cert per domain (I believe only for ECDSA certificates, aka ones that use their own CA), and caveat 2 is that you don't get the actual browser-trusted private key (of course the NSA could demand they turn it over).
Thanks for clarifying. My research there is a couple years old, but before posting I did some spot checking on CF-hosted domains and did see several using 1:1 certificates. They were all financial institutions, so I figured that there was a way to get Cloudflare to not lump them in with the unwashed masses. I did also still see domains secured by certs for dozens of domains.
I'm not sure I understand the 2nd caveat that you list. If Cloudflare issues a cert for a dozen different domains, there's one private key, right? Anyone with that private key could decrypt traffic going to any endpoint secured by that certificate?
Nope. Assuming you're using a modern client that's never how it works. Let's take TLS 1.3 where it's designed from the outset for this use case rather than retro-fitted. The effects are similar even in TLS 1.2 (with a modern client) but it's easier to follow in TLS 1.3
1. Client says "Hi, I'm guessing you are willing to use this elliptic curve key agreement method X, I picked a random number and so now I need to tell you a number I got based on that choice which is A"
2. Server says "OK method X works for me, I also picked a random number and I tell you B"
3. At this moment, Server knows an Ephemeral Secret Key for this TLS session, and as soon as it receives message (2) the Client will also know this key, but an eavesdropper won't know this key. Notice that nothing happened with any Private Keys or Certificates or anything yet!
4. Using the now Encrypted Channel with the Ephemeral Secret Key, the Server can present a Certificate, and prove its identity using the corresponding Private Key (optionally the client can do likewise).
Now, an _Active_ attacker can use the Private Key to impersonate a server and then proxy everything. But that's quite a step up from passively decrypting traffic. In Channel Binding scenarios the attacker would need to proxy the binding too, which will get out of hand pretty fast, since in TLS both parties have a per-channel secret and that secret won't match between the proxied and real channels.
I wonder how long it will take for conspiracy comments like these to pass.
Anyone know how long it took for people to trust Lets Encrypt? Or did we all forget (myself included) of the times when people talked about the issue of trusting some random 3rd party handing out free certificates?
If you mean mechanically, Let's Encrypt uses cross-signed intermediates.
What that means is, out of the box your Let's Encrypt cert comes supplied with a "chain" of two certificates, one says "Let's Encrypt says www.example.com has this public key K1, here's proof for Let's Encrypt's public key K2" and then the next says "Let's Encrypt key K2 is trusted on behalf of IdenTrust, here's proof for IdenTrust's key K3". The vast majority of clients in the Web PKI (including all popular web browsers when Let's Encrpyt launched) has baked in trust of IdenTrust via key K3. [ To see an example of what happens if you trust lots of other things from that era but not IdenTrust, try the web browser in a Nintendo WiiU]
In parallel the not-for-profit that delivers the Let's Encrypt service, ISRG, sought similar "root trust" in their own key, let's call this K4, and created certificates that says "Let's Encrypt key K2 is trusted on behalf of ISRG, here's proof for IdenTrust's key K4"
It took quite some time for the last major trust store to trust ISRG, Microsoft in I think 2018. And there will be lots of smaller or unmaintained trust stores that never catch up to this change.
In 2020 ISRG has said they plan to begin weaning people off the cross-signed intermediates, providing a chain with the ISRG signatures instead. In any vaguely modern web browser this will Just Work™ but avoids any problems if at some future date IdenTrust is no longer trusted and avoids ISRG needing continuing help from IdenTrust.
If you meant emotionally, I don't know. There are still plenty of people who feel sure that for some reason Let's Encrypt can't be any good because it doesn't cost money.
You don't need to trust Let's Encrypt anywhere near as much as you need to trust Cloudflare.
With Let's Encrypt, I generate my own encryption keys and never show the private key to anyone. LE just signs the public key. The risk is that they might also sign someone else's public key as being valid for my domain. But my servers will reject any traffic that isn't encrypted with my real public key. The best an attacker could do is set up a phishing operation.
But any CA can improperly sign a public key as being valid for my domain, not just LE. This is just a result of the CA system being broken by design.
On the other hand, Cloudflare is usually only useful if you let them terminate TLS on your behalf. So you have to give them your private key, and they really do have access to all of your traffic. At this point, they can do whatever they want with it, largely undetectably (i.e. without the risk of releasing obviously fake certificates into the wild).
If it's me browsing the web vs the NSA I'll throw in the towel right now. I'm not expecting DoH, or any protocol, to thwart the largest intelligence agencies in the world. I'm just looking for ISPs and free Wi-Fi hotspots to get a little better for the average user.
So they start with talking about ESNI and then kinda completely gloss over it afterwards. Yeah you can reuse the TLS session if several sites are using the same CDN, however, this is again relying on centralization for privacy.
The cool thing about DNS architecture is the fact that it is decentralized. Mozilla's plan with DoH tries to fix missing features in DNS by getting rid of arguably the biggest killer feature DNS has.
Furthermore, several governments use DNS right now to block websites deemed illegal in their country. Not just authoritarian states that attempt to censor material critical to the regime, but also western countries (copyright infringement, child porn, gambling, etc). Does Mozilla and Cloudflare seriously think they will just go "oh ok, I guess everything is unblocked again now". No, they will either force Cloudflare to do the same or force local ISPs to implement even stronger filtering controls.
There's a huge additional authoritarian step required to push MITM of all traffic. You cannot do that without people at the endpoints noticing. DNS-based "filtering" can pass unnoticed by many people; full MITM of all traffic cannot.
When a regime does something that only a small subset of people notice, it's easier to suppress that small subset of people, with a combination of PR and just ignoring them.
When a regime does something that everyone notices, it has to be prepared to be visibly acting against a large fraction of its people.
DoH won't stop a sufficiently determined regime from attempting to control the Internet, but it will stop less determined regimes from doing so quietly and getting away with it with minimal resistance, and not every regime is prepared for the implications and backlash of implementing country-wide MITM.
And on a more local scale, DoH also increases friction towards smaller entities trying to quietly control access to the Internet, such as ISPs or random wifi hotspots.
> Does Mozilla and Cloudflare seriously think they will just go "oh ok, I guess everything is unblocked again now". No, they will either force Cloudflare to do the same or force local ISPs to implement even stronger filtering controls.
We have an actual worked example to look at:
The British government decided that all pornography in the whole world should require proof of age so that British kids couldn't see it. They got all the legislation done, they got civil servants to write them a "White Paper" explaining how this would work, they selected a censor to manage the inevitable rulings saying that this or that pornographer didn't obey the rules and enforce DNS censorship.
And then, just weeks ago after much "delay" and "reconsideration", they U-turned. Because the part where you enforce the rules by "just" censoring DNS isn't practical under DPRIVE. You say they'll just "force" local ISPs to implement "even stronger filtering controls" but the only "stronger" option is to proxy all of HTTPS.
How were the IPSs going to pay for this? Mandatory price increases? Or are the government going to do the work and just raise taxes to pay for it? "Vote Conservative: Higher prices, worse service, more taxes, more censorship. Corruption and incompetence are our watchwords" ?
This works fine in China. The government wants to spend your money on a "Great Firewall"? Nothing you can do about it. Not so much in a country with anything resembling democracy left.
Aside: I've never understood how DNS is decentralized.
The internet: I get a number (from a central authority), I plug into other numbers, a path to my number appears. Sounds pretty decentralized once I have a number it's up to peering.
DNS: I get a name (from some authority) under a hierarchy. To look names up in this hierarchy you start with sanctioned root servers (from a central authority) which point you to TLD lookup servers (sanctioned by the same authority) which are the authority for that level and so on until you get to your name. Doesn't sound very decentralized, the only portion that's decentralized is the cache.
Anyways to your original point: I disagree losing a layer or two of distributed cache servers (depending on the deployment" is "the biggest killer feature DNS has" and I think encrypted randomization and stepping towards end to end integrity are better "killer features" that haven't been able to take off with traditional DNS.
> Furthermore, several governments use DNS right now to block websites...
So it has to be air tight in standing up to the worlds governments to provide value over being unauthenticated plain text? Even in the cases of governments you'd be surprised how far making it more difficult goes in the volume of collection or how it makes governments have to explicitly admit they are monitoring particular traffic due to the way the technologies work.
> Aside: I've never understood how DNS is decentralized.
I use my ISP's recursive DNS resolvers (or not); you use your ISP's recursive DNS resolvers (or not). Anyone that wants to track "everyone's" browsing has to track a whole bunch of ISPs (and 3rd party DNS operators) if they want to keep a database of activity. There is no central facility that has everyone's DNS requests, unlike (e.g.) MSN Messenger back in the day where all traffic was transferred through the central system.
Further, because of caching, it is impossible to get exact numbers on people querying DNS. So while the records for www.youtube.com are in a central place, the exact number of people sitting on their couches at home asking for the A record is masked by people's home routers doing caching and also their ISP DNS servers (which the home routers talk to) doing caching.
So there is no "central DNS" server that does hostname-to-IP mapping: there are (tens of) thousands--millions if you count people's home Linksys/Dlink/Asus routers running dnsmasq (or whatever).
I don't trust Mozilla anymore, especially after becoming a VPN vendor and partnering with Cloudflare. They now have commercial interests in pushing standards down on everybody, similar to Google.
My ISP (Entel Chile) started blocking DNS requests to non-Entel servers in July. DoT would not give me a way around this, because they can still see that it is DNS traffic by the port. DoH mixes DNS traffic in with the noise of HTTPS traffic, allowing me to run my own DoH resolvers and bypass their restrictions.
Once your ISP starts mucking with and blocking your traffic, what you need is a VPN and/or Tor – DoH is a very partial solution at best. What DoH gives you is merely a correct answer to a DNS lookup of an IP address. But if your ISP blocks traffic to that IP address, which they could, you’re still blocked; DoH did not help you.
The ISP is trying to block other DNS traffic, they're not necessarily trying to block certain websites (or if they are, they wouldn't want to block [for example] all of Cloudflare or the GCP load balancers to block porn hosted on either of those services). DoH solves that problem as directly as possible without going to solutions that have other side-effects.
The ISP do most certainly want to block web sites. The currently most common method is to block DNS, but they could, and will, switch to IP blocking in a heartbeat if they have to.
> they wouldn't want to block [for example] all of Cloudflare or the GCP load balancers
If your only defense against blocking by your ISP is to centralize web server hosting, then you’re just moving the problem to there instead. Cloudflare also blocks, or “deplatforms”, those they deem unseemly. And once someone is taken off the centralized web server hosts, they can be blocked by your ISP again. You’re not solving the problem in the long term.
Tor has limited value. Lots of things are blocked (search, for example), and it's slower than dialup. The security of the exit points is also questionable, and this is about trust.
Pushing all traffic through a VPN only moves the problem. Now I have to trust some unknown entity in some other country to respect my privacy. I don't want my traffic to bounce from Chile to Norway and then back to Chile when I do online banking. I run a VPN endpoint in Chile for my own traffic, but I don't need to push all of my home traffic through it....yet.
All useful traffic runs over HTTPS already, but metadata is still valuable. My ISP could snag SNI headers and know sites, but I don't think they're actively sniffing 100% of the traffic that goes across the wire. No, I think they want to be Verisign/Comcast/OpenDNS and redirect NXDOMAIN responses to ad pages or inject false responses to "unauthorized" queries.
That was true years ago, but nowadays I rarely percieve any speed difference at all when comparing browsing using Tor and non-Tor.
> Pushing all traffic through a VPN only moves the problem. Now I have to trust some unknown entity in some other country to respect my privacy.
But, and here’s the crucial difference: with VPNs you have a choice. A wide variety of choice. With ISPs, especially in the US, not so much.
> All useful traffic runs over HTTPS already, but metadata is still valuable. My ISP could snag SNI headers and know sites,
That’s due to be fixed with ESNI. Just wait for a technical fix.
> but I don't think they're actively sniffing 100% of the traffic that goes across the wire. No, I think they want to be Verisign/Comcast/OpenDNS and redirect NXDOMAIN responses to ad pages or inject false responses to "unauthorized" queries.
That is true today, but when DoH and/or DoT happens, the ISPs will certainly switch to doing whatever still works. They are merely sniffing and proxying DNS traffic today because it still works, but the second it no longer works, they will switch to whatever does work. You can’t just work around the current mechanisms, you have to look a few more moves ahead.
That was already a possibility even before all of this DoH publicity. Mozilla, etc. pushing DoH publicizes it's availability, but there was nothing in the past preventing malware from tunneling all sorts of traffic over HTTPS. DNS inspection isn't an end all, be all for malware security. It just gets the low hanging fruit.
There was a lot of low-hanging fruit given that most malware writers aren't going to set up all of this infrastructure for custom protocols.
And even when they did, creating various C&C servers, the lack of ESNI would allow for detecting activity once the daily domain creation algorithm was reverse-engineered:
This is possible regardless of whether Chrome/Firefox/etc deploy DoH support. In fact, it was possible before DoH at all: nothing mandated that malware use standard DNS requests on port 53.
Nothing requires malware to pick a “strange” port. It could just shove its data into ICMP, or make it look like an SSH connection on 22, or anything else.
Honestly, I don't see why people keep bringing this up. Malware has millions of ways of creating covert channels and you will never be able to block/detect all of them. It's also well within the capability of major DoH server operators to detect and shut down malware domains pretty fast.
If you're going to make these sorts of claims you need to also lay out how you logically came to them. What is the financial path incentive for Mozilla since they already have the ability access to anything about every page you ever go to? On the Cloudflare side have you looked into the resolver agreement and based your statement around those limitations or just your own conjecture https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... ?
DNSSEC doesn't provide privacy at all; it signs records, but doesn't encrypt queries or responses. So it's orthogonal to the DoH debate.
DoT does essentially the same thing that DoH does. The difference between DoT and DoH, from a practical perspective, is that DoT uses a new TCP port, and DoH overloads 443. The reason DoH overloads 443 is to make it difficult for network operators to disable. In other words: DoT is simply DoH with a network-controlled kill switch.
How exactly is DoT "more comprehensive" (to use the words from the tweet you've cited) than DoH?
As another post on HN argued a few weeks ago and as is stated in this article again:
> After you do the DNS lookup to find the IP address, you still need to connect to the web server at that address. To do this, you send an initial request. This request includes a server name indication, which says which site on the server you want to connect to. And this request is unencrypted.
Note that, until encrypted SNI is in place, DoH does not actually increase your privacy. Your ISP can still track all domains you connect to by analyzing the SNI header. The only thing they cannot do anymore is block or redirect any of the domains.
I'll say what has been said time and time again in the past: CF should not be the default server. There shouldn't be a default server. Have an onboarding flow that says "choose DNS server" and allow the user to choose between clearly-unencrypted endpoints (ISP/router, Google, quad9, etc) and encrypted endpoints that use DoH.
And again, Google's DoH solution is infinitely less controversial: an upgrade list[0] so that, if your computer/router advertises 1^4, it uses Cloudflare's DoH. If it advertises 8^4, it uses https://dns.google. It even works for a provider known as clean browsing[1] that filters DNS.
> However, we’ve spent time studying these risks… and we have negotiating power. We worked hard to find a company to work with us to protect users’ DNS data. And we found one: Cloudflare.
> Cloudflare is providing a recursive resolution service with a pro-user privacy policy. They have committed to throwing away all personally identifiable data after 24 hours, and to never pass that data along to third-parties. And there will be regular audits to ensure that data is being cleared as expected.
I think this is a fair and reasonable reason to land on Cloudflare if they are willing to cooperate in interest of the user and make their organization open to audits aligned to that.
I don't understand the hyped up hate on picking a default who is appearing to be going over the top as an ally for end users privacy, users aren't forced into staying with, and would be an arguably more transparent starting point than what people have today.
Reading what cloudflare sells, people who have a domains on Cloudflare and buy Pro, Business and Enterprise plan have access to DNS analytics that displays DNS queries from Cloudflares DNS servers, including geographic information.
Personally I don't see how that product can coexist with the privacy policy.
> Reading what cloudflare sells, people who have a domains on Cloudflare and buy Pro, Business and Enterprise plan have access to DNS analytics that displays DNS queries from Cloudflares DNS servers, including geographic information.
Those analytics are for authoritative queries against the domain(s) that you have on Cloudflare; not for queries to any domain.
Not logging _recursive_ queries against their public resolvers - and it's those recursive queries from end-users that hold the biggest risk to user privacy - is an entirely different thing, and these two systems can co-exist.
The distinction between authoritative and recursive queries is not meaningful in the context of DoH since that protocol is only about recursive servers. A user who connect to cloudflare through DoH is connecting through a recursive server, and knowing that the privacy policy say no logs, is unlikely to expect that logs are kept if the domain owner happens to be a customer of cloudflare.
Cloudflare could do as google and not include any query that comes via the public resolver. Any DoH query would thus be a blackhole in regard to analytics and only display data from users who used someone else recursive resolver for the query. In that way no logs from the public DNS resolver ever ends up as data, the privacy document is followed, and companies can not buy query data by becoming customers to Cloudflare.
The default should be to use the OS' DNS resolution library. DoH is almost like a VPN; AFAIK Firefox's proxy settings default to using the proxy server of the OS, so why should DNS be any different? I don't care if it's encrypted or not, I care whether applications respect the user by using the system's configuration. If I have the system configured to use a VPN, I expect all applications' traffic to get tunneled through it. The same for DNS and TCP and a lot of other services that the OS provides.
127 comments
[ 4.1 ms ] story [ 190 ms ] threadSometimes it feels that Mozilla is just paying token lip service to the idea of privacy.
Look a few years back and you’ll find similar enthusiastic comments about Google: they make everything better and for free. Everyone should use their search, everyone should move to GMail, etc.
Primarily because for beginners it's a bit easier to setup everything without much hassle.
DNS over HTTPS feels to me like we're edging towards end-to-end encryption for DNS. This seems like a good thing, but even though it will protect against ISP and state level observations of DNS, will it not reduce ones control over DNS locally?
My threat model remains web site operators and the malware and tracking inserted at that point. Additionally devices on the network that may observe locally and communicate externally like TV boxes and games consoles.
To manage those threats I use Pi-Hole. But once we start end-to-end encrypting, and especially when we start verifying those ends, how do I locally intercept and manage DNS for my privacy and security?
Is this a genuine concern about DNS over HTTPS? Or is the plan to enable systems like Pi-Hole to be a trusted and configurable resolver too so that consumers retain the ability to control their own systems like this?
(Edit: removed bit about root CA certs because I misunderstood)
I've completely blocked any outbound traffic to 8.8.8.8 and 8.8.4.4 from my network.
It won't if it defaults to centralized on-profit business like Cloudflare. They can tap for govts or sell aggregated data to ISPs someday. They aready own a lot of unencrypted traffic from TLS-termination.
Wouldn't it be better to use public/private key signing and onion-like infrastructure for DNS resolving and still keep it distributed?
No. Run your own DoH server, point your DoH client to your own DoH server, and your DoH server can then provide any responses you want. (And it in turn can use DoH or do standard recursive resolution.)
End-to-end encryption means that malicious parties can't MITM your traffic or otherwise make you talk to the wrong destination server. That doesn't prevent you from intentionally running your own local servers and pointing clients to them.
If you have a client device on your network that you don't trust and can't change the configuration of, it has far more secure methods for protecting itself from you than just using DoH.
No reason you can't get a real certificate, to ensure that your device talks to the server it intends to.
> If you're locked down... well, it's game over.
Devices today can already use pinned certificates and other similar measures to ensure that they only talk to the server they want to talk to. DoH doesn't make that any more or less effective, just simpler to get right.
You'd have to get a certificate for whatever domain the device wants to talk to - a domain you very likely have no control over.
No sane CA will give you a cert for that. The whole point of the PKI is to keep MITMs from pretending to be domains that they actually don't control - which is exactly what we'd be doing here.
If 90% of users leave it as shipped set to (say) Google, 9% switch to their preferred service and only a handful like you actually type in a DNS name, that freedom to do is preserved. If it doesn't check the certificate from the DoH server when you override the configuration, you are immediately exposed to a MITM so it needs to check. However you'll have no trouble getting a cert for your own FQDN, and that's what the poster you replied to is thinking of.
I believe there are ideas for a network-level autodiscovery of DoH servers, analogous to regular DNS. That would solve the problem, but I can't see how it would get buy-in from the DoH crowd, as it would tie DNS to the network again - and it would still have to be implemented by every single device.
Of course all of this is moot if the vendor actively wants to prevent you from intercepting DNS.
And don't forget that you can change the resolver today, as you can install uBO, but what about tomorrow?
Except when the client ignores what you tell it. Per Paul Vixie:
* https://news.ycombinator.com/item?id=19170671Of course with DoH you can't just do a UDP redirect. With DoT, which uses tcp/953, you can at least block access.
But with DoH, you have just lost control of your network. (Unless block 443 and force everything to go through a (Squid) proxy?)
Expect “enterprise” network equipment using an approach like this to provide a “DOH firewall” in the near future.
Net privacy gained: negative.
The goal for DoH is to improve privacy for individual humans, and it does that.
Sometimes you don't choose the software, the software chooses you:
* https://www.zdnet.com/article/first-ever-malware-strain-spot...
* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...
I'm happy to implement DoT on work's network to help encourage encrypted DNS. My problem is DoH can now be used by all sorts garbage and we can't tell it from legitimate HTTPS--which is by design.
All this for the laudable goal of protecting Internet surfers' privacy. However I'm curious to know how well this will work against the Great Firewall of China, and how many other regimes will now implement Great Firewalls of their own.
Malware can ship with an arbitrary number of DNS-over-HTTPS servers accessible anyway, no matter whether Google supports it. The cat was out of the bag as soon as you allowed encryption on your network in general.
Finally, there are system architectures that are inherently less susceptible to malware, which is what we should really be focusing on. If your document viewer doesn't need to access the Internet, why does it have access to the Internet? Why does your general-web-browsing browser have access to your intranet and worse, your network drives and USB sticks? The reason we're stuck with what we have now is that operating systems research largely died in the 90s, but we're now aware that e.g. microkernel capability systems can be implemented in ways that are both fast and secure.
[1] https://www.cs.kau.se/philwint/scramblesuit/wpes2013.pdf
If you can't trust your device, you can't trust it without DoH either. As I said upthread, devices don't even need to use DNS. They can open up encrypted C&C channels, using whatever protocol they'd like, tunneled over whatever they'd like. They can bake rendezvous IP addresses in, they can cryptographically verify endpoints to break MITM proxies, they can even sneak data out in ICMP packets. DoH has literally nothing to do with it.
What's insidious about this argument is that it preys on peoples legitimate concerns about uncontrolled devices on their network. We're all concerned about that! But that doesn't mean we should use plaintext DNS, or Paul Vixie's preferred "encrypted DNS with a killswitch for network operators".
Might as well argue against using windmills to grind wheat.
What DOH client would that be? Where would I configure it? How do I configure a systemwide DOH setting?
Right now none of those questions can be given a simple answer. DOH is a rogue technology.
In July of this year my ISP (Entel Chile) started blocking all ICMP and DNS to non-Entel resolvers. They will not respond to tickets requesting an explanation or confirmation - DNS and ICMP just went dark. In response, I set up DoH on my Pi-Hole with the instructions above.
I don't trust Cloudflare, so a couple weeks ago I started modifying the tools from doh-proxy [2] to run in a container [3]. I have this running in three locations under my control, in networks that I trust (or at least that I trust more than Cloudflare), and in one location I run a proxy that uses Nginx to load-balance requests across the multiple locations.
I made two videos that show how you can set this up, first about the proxy [4] and how to run a stub DNS-to-DoH forwarder in Docker on your local machine if you don't control the network DNS server, and then about how to set up your own private DoH resolvers in Kubernetes (using a $5 VPS and running k3s) [5].
These solutions, while more technical than what my mom can put together, will not only use systems that you control, but depending on how you set it up, will encrypt all DNS traffic from your machine. Encrypting browser traffic is good for the masses, but it only solves a small part of the problem.
Even if you only use the proxy, you can forward to public DoH resolvers that include parental filters, adblocking, and other benefits. If you don't have a Pi-Hole or can't run one, you can get the same benefits with a service like NextDNS [6], who have a generous free tier.
The next step is to configure the resolver to support auth, so that it's not all just hanging out on the Internet like it is at the moment.
For those who are asking about malware and if DoH makes it easier - consider that this is an HTTPS request. All any malware has to do (and already does) is bypass your system's DNS configuration and make the HTTPS request for DNS resolution of C2 systems directly. Whether or not you have DoH active on your system for other requests is irrelevant.
[1]: https://docs.pi-hole.net/guides/dns-over-https/
[2]: https://github.com/facebookexperimental/doh-proxy
[3]: https://hub.docker.com/r/monachus/doh-tools
[4]: https://youtu.be/1RTHCieZqls
[5]: https://youtu.be/Z-_SpFWloQo
[6]: https://nextdns.io
Edit: Link formatting
Devices already use pinned certificates, but DoH gives the device manufacturer a convenient and unblockabke way to resolve names against a trusted server. Device manufacturers could be jerks already, but I'd argue that DoH lowers the barrier-to-entry for being a jerk.
Consumers don't, by and large, give a damn about whether they actually own their devices or not. This is yet another reason why those of us who care about ownership and control of our own networks can't have the cool new "toys". We're back to feudalism.
Well, with regular DNS, you can force-route 8.8.8.8 to pi-hole and regain control relatively easily.
That's not possible with DoH due to TLS.
Yeah static IP routing is an option - for both nameservers and nefarious servers. That is, we may just have to resort to using IP blocks.
Call it the opposite of defense-in-depth. Device manufacturers who aren't thorough might allow a class of "attacks" by way of using DNS. Having ubiquitous DoH takes away that "attack" vector.
I'm not arguing device manufacturers need DoH to be jerks. Having it available just enables the less sophisticated ones to be jerky more easily. DNS-over-TLS does the same thing, it's just marginally less frustrating because it can be blocked at the network layer, at least.
I understand that allowing owners of devices to do what they want on their own networks runs counter to the whole "protect the public from bad network operators" / "protect the public from bad people" narrative. I'm in the minority. It's just damned frustrating. It's sucking all the fun out of computing and networking. It's irrational and self-serving, but dammit it makes me angry.
You see, one thing is one or two vendors misusing protocols to remove users control from their devices. Another thing is an official protocol that does the same thing. We find have anywhere to run anymore.
As bi dollar corporations and organizations are more and more "protecting" ourselves they need to remove control from ourselves.
And now that it's being marketed heavily, it just gave them another reason to do it that they didn't have before ("Mozilla is doing it too!")
DNS yes but IP will be observed and censored eventually.
DoH is not effective against gov censuring that's just propaganda.
So why push DoH so hard? Because it moves DNS control to developers
Isn't the real problem that you don't control the device in the first place? Perhaps the better solution is to only run devices and software that you can actually trust, if the security of those devices is important to you, or if you care about the device's behavior.
DNS was a passable solution in the 80s, but right now it's absolute shit.
Yes some middle parties won't be able to tamper with my DNS queries. At what price? Total control for the people providing the DOH endpoints. So chrome for sure will be using Google DNS for this, and with their efforts to remove ad blocking this fits nicely that you won't be able to use simply DNS based blocker.
This proposal doesn't solve this problem. Rather, it solves the problem of e.g. your ISP intercepting, logging and/or modifying your DNS request.
The solution will then just be to run your own DoH endpoint / proxy.
[0]: https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red...
Right now I have my own dns configuration on my router, and any device that connects to the router is automatically using this dns. With DOH this doesn't seem to be the case though. I'll need to go and change the settings for each device to use my own DOH proxy. But whether I'll be allowed to do so is quite unclear if you ask me.
Becauae what happens when chrome says : "we have you covered, it's best to use only our DNS over HTTPS. If you need something else you can buy enterprise subscription"
But I think what they need is screw all of us, in a way which we won't resist much because it's for our own good.
This could have been DNS over TLS, or any other form of encryption. But it is DNS over HTTPS. This makes sense only for a browser, because they have the https stack already. But if we are talking about libc, it's very different story, there is no Http, let alone HTTPS there.
So does DNS over TLS (DoT). But the Mozilla folks don't seem to be interested in implemented that for some reason.
A little historical similarity, ISP used to provide a default MTA servers just like they do with resolver. Now days it most people use a email provider of choice.
So lets now imagine we solved the plain text problem of email by having the client use a default list of trusted MTA, with thunderbird defaulting to partner with gmail, and just sent it there over HTTPS. Gmail would take the email and forward it in plaintext to the recipient-server.
Email security did not follow that path. There we collectively decided to first encrypt communication between the client and the MTA using TLS, addressing the first step in the chain. Then the communication between MTA and recipient server got encrypted. In order to prevent downgrade attacks there is also currently two competing standards, one based on DNS and the other on HTTPS side channel. Looking at email, we are also almost done converting the plain text protocol to encrypted: https://transparencyreport.google.com/safer-email/overview
The general question is then, why not just copy the success of email? The answer it seem is about money. No company got more users or data when email protocols got encrypted. Cloudflare however will benefit if everyone route their DNS through them as that gives them a comparable performance benefit when people use them as a hosting provider. They also say they won't sell data, but people who move their domain hosting to cloudflare and pay for Pro, Business and Enterprise plan can get access to DNS analytics.
Shortly after DoT and DoH came along as standardized proposals with fewer NIH issues and more interoperability. DoH also has the bonus of looking like standard HTTPS traffic to the resolver. Technically e.g. Google could host DoH on google.com/dns-query and it would be hidden in the deluge of HTTPS that already goes to google.com.
https://dnscrypt.info
The protocol was recently extended with Anonymized DNS, a mechanism that hides client IP addresses from resolvers by using relays dedicated to secure DNS forwarding. A new network of DNS relays is currently being deployed.
https://www.reddit.com/r/dnscrypt/comments/dhoxah/anonymized...
dnscrypt-proxy, the reference client implementation, is at version 2.0.29.beta3, released yesterday.
There is a new, easy to use and deploy implementation in Rust to add DNSCrypt support server-side, Encrypted DNS Server: https://github.com/jedisct1/encrypted-dns-server
DoH, DNSCrypt and DNS relaying can happily share the same TCP port 443.
A complete protocol description has been available for years, but turning it into an IETF document is time consuming. It will eventually happen, but as an independent project, writing software has been prioritized over marketing.
Yes, they don't use a simple trusted list, but some secret Algorithm. The effect is the same (or maybe it's worse, since if the Algorithm doesn't like you, there's no one to ask to add you to the list).
The security improvements you mention were more or less pushed onto others by Google and everybody was forced to implement them since if you can't talk to GMail you might as well as not exist in the SMTP world.
> No company got more users or data when email protocols got encrypted
This is speculation, but it's easy to see how these changes could have benefited big players: they already have the data. By forcing encryption on everyone they deny this information to others (like ISPs who might sniff the traffic).
Also these security improvements increase the burden of maintenance of small mail servers, which again pushes more users towards big players.
I'm not saying encrypting SMTP traffic didn't benefit the users, but reasons for forcing it on everyone might not have been completely altruistic.
So no, not a rounding error and gmail is definitive not Email nor even 50% of it. Discussing market share also seems to me as very much the wrong question. Why should we not use the same process that email did when the world converted over to using encrypted email between client->MTA->Recipient? Is there a technical argument why converting things to HTTPS and then giving everything to whomever the browsers is partnered with is a better model?
Someone once pointed out that if the NSA wanted to build a front company whose goal was to make hoovering up the internet easier, it would probably look a lot like Cloudflare. I'm generally not much of a conspiracy theorist, but this one has been frustratingly difficult to shrug off.
Cloudflare is a US company and subject to US coercion. It would be trivial for the US to force Cloudflare to give them access to that data, and with Cloudflare currently decrypting ~10% of all Internet traffic, why wouldn't they?
How about the fact that Cloudflare-issued certificates are for dozens of domains? If the US wants to snoop on foreign domain X, a US order for US domain Y, also on the same cert, would give them the private key.
It's not possible to detect abuse in this system. It requires that we trust the state to not abuse their power, and we've seen them lie about that already.
The mere fact that the Cloudflare system _can_ be abused is, in my opinion, enough reason to go nowhere near it for anything.
> How about the fact that Cloudflare-issued certificates are for dozens of domains? If the US wants to snoop on foreign domain X, a US order for US domain Y, also on the same cert, would give them the private key.
Caveat 1 is that they've started to issue 1 cert per domain (I believe only for ECDSA certificates, aka ones that use their own CA), and caveat 2 is that you don't get the actual browser-trusted private key (of course the NSA could demand they turn it over).
I'm not sure I understand the 2nd caveat that you list. If Cloudflare issues a cert for a dozen different domains, there's one private key, right? Anyone with that private key could decrypt traffic going to any endpoint secured by that certificate?
1. Client says "Hi, I'm guessing you are willing to use this elliptic curve key agreement method X, I picked a random number and so now I need to tell you a number I got based on that choice which is A"
2. Server says "OK method X works for me, I also picked a random number and I tell you B"
3. At this moment, Server knows an Ephemeral Secret Key for this TLS session, and as soon as it receives message (2) the Client will also know this key, but an eavesdropper won't know this key. Notice that nothing happened with any Private Keys or Certificates or anything yet!
4. Using the now Encrypted Channel with the Ephemeral Secret Key, the Server can present a Certificate, and prove its identity using the corresponding Private Key (optionally the client can do likewise).
Now, an _Active_ attacker can use the Private Key to impersonate a server and then proxy everything. But that's quite a step up from passively decrypting traffic. In Channel Binding scenarios the attacker would need to proxy the binding too, which will get out of hand pretty fast, since in TLS both parties have a per-channel secret and that secret won't match between the proxied and real channels.
Anyone know how long it took for people to trust Lets Encrypt? Or did we all forget (myself included) of the times when people talked about the issue of trusting some random 3rd party handing out free certificates?
What that means is, out of the box your Let's Encrypt cert comes supplied with a "chain" of two certificates, one says "Let's Encrypt says www.example.com has this public key K1, here's proof for Let's Encrypt's public key K2" and then the next says "Let's Encrypt key K2 is trusted on behalf of IdenTrust, here's proof for IdenTrust's key K3". The vast majority of clients in the Web PKI (including all popular web browsers when Let's Encrpyt launched) has baked in trust of IdenTrust via key K3. [ To see an example of what happens if you trust lots of other things from that era but not IdenTrust, try the web browser in a Nintendo WiiU]
In parallel the not-for-profit that delivers the Let's Encrypt service, ISRG, sought similar "root trust" in their own key, let's call this K4, and created certificates that says "Let's Encrypt key K2 is trusted on behalf of ISRG, here's proof for IdenTrust's key K4"
It took quite some time for the last major trust store to trust ISRG, Microsoft in I think 2018. And there will be lots of smaller or unmaintained trust stores that never catch up to this change.
In 2020 ISRG has said they plan to begin weaning people off the cross-signed intermediates, providing a chain with the ISRG signatures instead. In any vaguely modern web browser this will Just Work™ but avoids any problems if at some future date IdenTrust is no longer trusted and avoids ISRG needing continuing help from IdenTrust.
If you meant emotionally, I don't know. There are still plenty of people who feel sure that for some reason Let's Encrypt can't be any good because it doesn't cost money.
With Let's Encrypt, I generate my own encryption keys and never show the private key to anyone. LE just signs the public key. The risk is that they might also sign someone else's public key as being valid for my domain. But my servers will reject any traffic that isn't encrypted with my real public key. The best an attacker could do is set up a phishing operation.
But any CA can improperly sign a public key as being valid for my domain, not just LE. This is just a result of the CA system being broken by design.
On the other hand, Cloudflare is usually only useful if you let them terminate TLS on your behalf. So you have to give them your private key, and they really do have access to all of your traffic. At this point, they can do whatever they want with it, largely undetectably (i.e. without the risk of releasing obviously fake certificates into the wild).
The cool thing about DNS architecture is the fact that it is decentralized. Mozilla's plan with DoH tries to fix missing features in DNS by getting rid of arguably the biggest killer feature DNS has.
Furthermore, several governments use DNS right now to block websites deemed illegal in their country. Not just authoritarian states that attempt to censor material critical to the regime, but also western countries (copyright infringement, child porn, gambling, etc). Does Mozilla and Cloudflare seriously think they will just go "oh ok, I guess everything is unblocked again now". No, they will either force Cloudflare to do the same or force local ISPs to implement even stronger filtering controls.
When a regime does something that only a small subset of people notice, it's easier to suppress that small subset of people, with a combination of PR and just ignoring them.
When a regime does something that everyone notices, it has to be prepared to be visibly acting against a large fraction of its people.
DoH won't stop a sufficiently determined regime from attempting to control the Internet, but it will stop less determined regimes from doing so quietly and getting away with it with minimal resistance, and not every regime is prepared for the implications and backlash of implementing country-wide MITM.
And on a more local scale, DoH also increases friction towards smaller entities trying to quietly control access to the Internet, such as ISPs or random wifi hotspots.
We have an actual worked example to look at:
The British government decided that all pornography in the whole world should require proof of age so that British kids couldn't see it. They got all the legislation done, they got civil servants to write them a "White Paper" explaining how this would work, they selected a censor to manage the inevitable rulings saying that this or that pornographer didn't obey the rules and enforce DNS censorship.
And then, just weeks ago after much "delay" and "reconsideration", they U-turned. Because the part where you enforce the rules by "just" censoring DNS isn't practical under DPRIVE. You say they'll just "force" local ISPs to implement "even stronger filtering controls" but the only "stronger" option is to proxy all of HTTPS.
How were the IPSs going to pay for this? Mandatory price increases? Or are the government going to do the work and just raise taxes to pay for it? "Vote Conservative: Higher prices, worse service, more taxes, more censorship. Corruption and incompetence are our watchwords" ?
This works fine in China. The government wants to spend your money on a "Great Firewall"? Nothing you can do about it. Not so much in a country with anything resembling democracy left.
The internet: I get a number (from a central authority), I plug into other numbers, a path to my number appears. Sounds pretty decentralized once I have a number it's up to peering.
DNS: I get a name (from some authority) under a hierarchy. To look names up in this hierarchy you start with sanctioned root servers (from a central authority) which point you to TLD lookup servers (sanctioned by the same authority) which are the authority for that level and so on until you get to your name. Doesn't sound very decentralized, the only portion that's decentralized is the cache.
Anyways to your original point: I disagree losing a layer or two of distributed cache servers (depending on the deployment" is "the biggest killer feature DNS has" and I think encrypted randomization and stepping towards end to end integrity are better "killer features" that haven't been able to take off with traditional DNS.
> Furthermore, several governments use DNS right now to block websites...
So it has to be air tight in standing up to the worlds governments to provide value over being unauthenticated plain text? Even in the cases of governments you'd be surprised how far making it more difficult goes in the volume of collection or how it makes governments have to explicitly admit they are monitoring particular traffic due to the way the technologies work.
I use my ISP's recursive DNS resolvers (or not); you use your ISP's recursive DNS resolvers (or not). Anyone that wants to track "everyone's" browsing has to track a whole bunch of ISPs (and 3rd party DNS operators) if they want to keep a database of activity. There is no central facility that has everyone's DNS requests, unlike (e.g.) MSN Messenger back in the day where all traffic was transferred through the central system.
Further, because of caching, it is impossible to get exact numbers on people querying DNS. So while the records for www.youtube.com are in a central place, the exact number of people sitting on their couches at home asking for the A record is masked by people's home routers doing caching and also their ISP DNS servers (which the home routers talk to) doing caching.
So there is no "central DNS" server that does hostname-to-IP mapping: there are (tens of) thousands--millions if you count people's home Linksys/Dlink/Asus routers running dnsmasq (or whatever).
A better solution would be DoT+DNSSEC: https://twitter.com/jschauma/status/1184483451111727106
I don't trust Mozilla anymore, especially after becoming a VPN vendor and partnering with Cloudflare. They now have commercial interests in pushing standards down on everybody, similar to Google.
> they wouldn't want to block [for example] all of Cloudflare or the GCP load balancers
If your only defense against blocking by your ISP is to centralize web server hosting, then you’re just moving the problem to there instead. Cloudflare also blocks, or “deplatforms”, those they deem unseemly. And once someone is taken off the centralized web server hosts, they can be blocked by your ISP again. You’re not solving the problem in the long term.
DoH is fighting yesterday’s war.
Pushing all traffic through a VPN only moves the problem. Now I have to trust some unknown entity in some other country to respect my privacy. I don't want my traffic to bounce from Chile to Norway and then back to Chile when I do online banking. I run a VPN endpoint in Chile for my own traffic, but I don't need to push all of my home traffic through it....yet.
All useful traffic runs over HTTPS already, but metadata is still valuable. My ISP could snag SNI headers and know sites, but I don't think they're actively sniffing 100% of the traffic that goes across the wire. No, I think they want to be Verisign/Comcast/OpenDNS and redirect NXDOMAIN responses to ad pages or inject false responses to "unauthorized" queries.
That was true years ago, but nowadays I rarely percieve any speed difference at all when comparing browsing using Tor and non-Tor.
> Pushing all traffic through a VPN only moves the problem. Now I have to trust some unknown entity in some other country to respect my privacy.
But, and here’s the crucial difference: with VPNs you have a choice. A wide variety of choice. With ISPs, especially in the US, not so much.
> All useful traffic runs over HTTPS already, but metadata is still valuable. My ISP could snag SNI headers and know sites,
That’s due to be fixed with ESNI. Just wait for a technical fix.
> but I don't think they're actively sniffing 100% of the traffic that goes across the wire. No, I think they want to be Verisign/Comcast/OpenDNS and redirect NXDOMAIN responses to ad pages or inject false responses to "unauthorized" queries.
That is true today, but when DoH and/or DoT happens, the ISPs will certainly switch to doing whatever still works. They are merely sniffing and proxying DNS traffic today because it still works, but the second it no longer works, they will switch to whatever does work. You can’t just work around the current mechanisms, you have to look a few more moves ahead.
And when malware gets on your network and starts using DoH to get around your home resolvers, what will you do?
* https://www.zdnet.com/article/first-ever-malware-strain-spot...
* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...
As someone who works in IT, this is my problem with DoH.
And even when they did, creating various C&C servers, the lack of ESNI would allow for detecting activity once the daily domain creation algorithm was reverse-engineered:
* https://blog.malwarebytes.com/security-world/2016/12/explain...
Except using other ports would cause network monitoring software to throw red flags because of the "strange" traffic on non-standard ports.
DoT does essentially the same thing that DoH does. The difference between DoT and DoH, from a practical perspective, is that DoT uses a new TCP port, and DoH overloads 443. The reason DoH overloads 443 is to make it difficult for network operators to disable. In other words: DoT is simply DoH with a network-controlled kill switch.
How exactly is DoT "more comprehensive" (to use the words from the tweet you've cited) than DoH?
> Avoid untrustworthy resolvers by using Trusted Recursive Resolver.
If it's to trust a resolver just 1.1.1.1 (or whatever)
> Protect against on-path eavesdropping and tampering using DNS over HTTPS.
This is the only real change but it is useless for everything outside a CDN Whit is basically everything that matters for users
> Transmit as little data as possible to protect users from deanonymization.
QNAME minimization can be done already, it is not a DoH thing
> After you do the DNS lookup to find the IP address, you still need to connect to the web server at that address. To do this, you send an initial request. This request includes a server name indication, which says which site on the server you want to connect to. And this request is unencrypted.
Note that, until encrypted SNI is in place, DoH does not actually increase your privacy. Your ISP can still track all domains you connect to by analyzing the SNI header. The only thing they cannot do anymore is block or redirect any of the domains.
https://news.ycombinator.com/item?id=17196415
And again, Google's DoH solution is infinitely less controversial: an upgrade list[0] so that, if your computer/router advertises 1^4, it uses Cloudflare's DoH. If it advertises 8^4, it uses https://dns.google. It even works for a provider known as clean browsing[1] that filters DNS.
0: https://blog.chromium.org/2019/09/experimenting-with-same-pr...
1: https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd...
Do you believe you are selecting the path of least resistance?
How many defaults in systems do you use today so you aren't configuring the dials and knobs of a spaceship everytime you power on.
Using Cloudflare as a default vs the ISP's defaults.
If you care you can learn and change them the same way we operate today.
The browser is a product, UX wins. How do I make my product easy to use while still maintaining a security forward stance? Defaults.
> Cloudflare is providing a recursive resolution service with a pro-user privacy policy. They have committed to throwing away all personally identifiable data after 24 hours, and to never pass that data along to third-parties. And there will be regular audits to ensure that data is being cleared as expected.
I think this is a fair and reasonable reason to land on Cloudflare if they are willing to cooperate in interest of the user and make their organization open to audits aligned to that.
I don't understand the hyped up hate on picking a default who is appearing to be going over the top as an ally for end users privacy, users aren't forced into staying with, and would be an arguably more transparent starting point than what people have today.
Personally I don't see how that product can coexist with the privacy policy.
Those analytics are for authoritative queries against the domain(s) that you have on Cloudflare; not for queries to any domain.
Not logging _recursive_ queries against their public resolvers - and it's those recursive queries from end-users that hold the biggest risk to user privacy - is an entirely different thing, and these two systems can co-exist.
Cloudflare could do as google and not include any query that comes via the public resolver. Any DoH query would thus be a blackhole in regard to analytics and only display data from users who used someone else recursive resolver for the query. In that way no logs from the public DNS resolver ever ends up as data, the privacy document is followed, and companies can not buy query data by becoming customers to Cloudflare.