And how do these sophisticated users populate their own revolvers if not plain DNS, DNS over TLS, or DNS over HTTPS? There is no such thing as hosting a globally distributed database from your house.
Agreed, SNI and DNS need to be fixed together, not separately. And definitely without centralized services, like Cloudflare. Otherwise why not just go all the way with centralization and provide secure proxy for everyone in the browser.
They are completely independent protocols, with their own issues in this area.
For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view.
Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale.
Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol.
There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale.
At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.
They are mostly independent. Your privacy loss is by and large the sum (or max) of the privacy loss caused by DNS and TLS individually.
For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare.
For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers.
At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.
Ironically, some amount of centralisation can improve privacy. Security is about confusion and diffusion; to get lost in a crowd you need to not be differentiated, and to not be the whole crowd. Encrypted SNI would mean ISPs could tell you were contacting Cloudflare servers, but not which of the many hosted websites you were requesting (assuming you also plug the DNS privacy gap too).
You can't wiretap the DNS and obtain data about all site visits from there. That's really quite nice.
It still means that your ISP or a wiretap on your own internet pipe can check your browsing activity by monitoring SNI's, but then again, they can also figure that out for a lot of sites by just checking the IP.
Then you could argue that all sites should use CDNs to hide this, but then you open the argument of whether the internet should be centralized or decentralized.
Encrypted SNI would be nice, but are tricky (wouldn't work well in multi-tenant setups), and those that can sniff the SNI probably know where you were going anyway.
I was curious about TLS1.3’s attempt to encrypt SNI, and found that it is genuinely a hard problem. The best solution seemed to be to use a proxy/fronting service, but that isn’t the ideal solution.
Encrypted SNI is very hard. The TLS working group agreed a problem statement, seeing out what should be achieved, but they haven't found any viable way forward on achieving that.
If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do. Bob has no way to know I'm even trying to contact him, so he can't help.
> If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do
You can tell a few people near you that "someone" wants to tell something to Bob and an answer from Bob. They tell people near them and so on, until it reaches Bob. He then answers and tells people near him, they tell those who told them and so on, until the answer is delivered back to you. And since no one can hear what people tell each other, no one can assume that "someone" is you and not someone else talking to you in secrecy, many connections away from you.
Think overlay peer-to-peer networks.
But the minimum viable threat model is ISP appliances that do classification and identification of traffic, both passively and actively, like trying to probe for protocols and hostnames. If you are not targeting them, you are effectively doing nothing, but pretend privacy PR. Which is the case with Cloudflare's DNS.
You yell "Hey, Zanizabo, call Fylnatis" at the top of your lungs. Zanizabo being a phrase encrypted such that only Bob knows you are talking to him, and Fylnatis is your similarly encrypted contact information.
For this to work you unsolve the key-sharing problem. Everybody who will ever want to communicate with anybody must agree in advance shared secrets with every such party and then retain them indefinitely. You assert the resulting scaling "is harder, but it's not impossible" and I'm sure that by some technical definition of "impossible" this statement is even true, but in practical terms it's never going get done which is why such systems are used (if at all) only by secret agents.
If you decide well that's OK, we can do something simpler - everybody will have an infinite set of aliases like "Zanizabo" or "Fylnatis" but they won't be one-to-one shared secrets, alas Mallory simply hears you say "Zanizabo" and she says "Hey, Zanizabo, call Oxymoron" (Oxymoron is an alias Mallory has chosen for this purpose) and soon discovers that Bob answers so now she knows who you wanted to talk to.
> but I refuse to let anybody know that I want to communicate with Bob
That's not the problem though. You're not trying to stop an eavesdropper knowing you're communicating with a particular server, but rather which hostname you're talking to them as.
To extend the Bob analogy; you're not trying to hide that you're communicating with Bob, but that you're speaking to each other as members of Fight Club.
It's certainly not impossible, although overcoming issues of scaling or increased handshake round trips is a difficulty.
You say "difficulty", the evidence seems to suggest impossibility. I am 100% certain that if you have an actual plan for how to do this without an extra round trip the TLS WG wants to hear about it (but please read the draft with the problem statement first so that you don't embarrass yourself and propose something that doesn't actually solve the problem)
In order to be sure we're talking to Bob, so that it's OK if Bob knows we want his Fight Club certificate, I think we have to incur an extra round trip while we obtain the proof he's Bob and send back the request for Fight Club.
If we try to skip that step, Mallory simply interposes, we send our message to Mallory, believing she is Bob, and she reads it to determine we want Fight Club, we are undone. So we have to wait until Bob proves his identity, and only then reveal that we wanted Fight Club.
Forgive me if there's some flaw I've overlooked in this approach, but couldn't you use DNS to aid in this? I.e. add Bob's public key to the DNS for fight.club which you get for free in round trips, as you're resolving the A & AAAA records anyway. You then encrypt the SNI asking for fight.club (along with a random nonce) with Bob's pubkey.
Of course, this approach would require the DNS record is authenticated, so DNSSEC is a must, added to which the DNS resolution must be encrypted, so DNS over HTTPS, DNSCurve, etc.
After some thought I agree with you that this can work, if you have encrypted DNS and DNSSEC in play. I am of course not a world-renowned expert so maybe we both overlooked something.
Two small problems I will mention, one of which I'm sure you already know: First, encrypted DNS and DNSSEC are not yet widely deployed, so this isn't the silver bullet many people expected of Encrypted SNI.
Second, for an endpoint which has many unrelated names and certificates - which is the case where encrypted SNI is gaining us a clear security benefit given our packets must have a plaintext IP destination - now they need to try every possible private key to see if they can open our encrypted SNI. This might be a very considerable burden.
> now they need to try every possible private key to see if they can open our encrypted SNI.
The idea was to have a single common introductory keypair which all tenants publish to their DNS, in order to encrypt the SNI. That way there is no need to try multiple private keys.
The lack of DNSSEC deployment is an issue, although there's nothing to stop such schemes being employed on an opportunistic basis. However, when DNSSEC is available for a domain, the scheme should be enforced to prevent a MITM attack.
Well, Diffie-Hellman Key Exchange does something similar.
Create a key out of nowhere for 2 parties to boot strap communicate safely. (obviously Diffie-Hellman doesn't solve all problems like knowing who you are actually talking to)
SNI doesn't encrypt the hostname but in TLS 1.3 it does secure it against middleboxes. If a MitM tries to alter the SNI then the connection fails.
TLS 1.3 also encrypts the server certificate. So if you want to send bonus SNI but get back real certificates that's just a matter between client and server.
The use case for Encrypted SNI remains sketchy. If I am the secret police of some authoritarian nation, who would block diebartdie.example why wouldn't I instead block the IP addresses of servers offering diebartdie.example? Only because it causes collateral damage? But why do I care, teach them not to associate with my enemies.
> Only because it causes collateral damage? But why do I care
Because the collateral damage may not be worth it. The website a handful of dissidents use may not be worth blocking everything running on Cloudflare for all your citizens, for instance.
Because there is no encryption, other devices along the way might collect (or even block or change) this data too.
...which is sometimes very desirable[1][2][3]. I get the whole "more security!" movement, but also feel like it's just contributing to turning general-purpose computers into locked-down media consumption devices.
#1 and #2 are not hindered by "more security". They're local proxies you set up and decide to trust. In a proper setup, you would use encrypted communication towards that proxy, and that proxy would use encrypted communication towards the appropriate server, maintaining privacy and authentication while implementing their purpose. Both of them are a bit of a hack, though, as this really belongs in the client application.
More generally, more security does not stop any legitimate use-cases. You just chose to extend your trust.
#3 doesn't have anything to do with the subject at hand.
Network interception is never something a user wants, and does not implement additional security. It's common in enterprise and banking environments for all the wrong reasons (enough that these industries were trying to harm TLS1.3 when they realized that the increased security was troublesome). Such a setup is by no means necessary, and due to there being Bad People in this world, the ability to do so is dangerous.
Repressive governments that wish to control or manipulate information is a very good example, and sacrificing silly enterprise politics is a very small price to pay to help the repressed. The result of There are quite a few places where this is the case, even though it might be hard to imagine for someone in the west (despite filtering occurring in the west too, whenever the government dislikes a site).
It's a more privacy movement, not a more security movement. None of this really affects security at all. They're only using encryption because it obscures things. We already have DNSSEC to ensure integrity and authenticity, which is what these DNS-over-HTTP providers will be doing on their side anyway.
"On the Firefox network and security teams, we’re working to change that by encrypting DNS queries and by testing a service that keeps DNS providers from collecting and sharing your browsing history."
Adding an authentication header prevents alteration but it does not present a viable option to the problem statement.
so, there's a concurrent post about how 1.1.1.1 had an outage. Does that mean web browsing won't work if that happens again? If not, does that mean it will fallback to unencrypted DNS if 1.1.1.1 is blocked?
Making this a default means that Firefox users all bypass censorship in several countries, what do they expect to happen as a result of it? Firefox blocked? 1.1.1.1 blocked?
This isn't any different from if your normal DNS server is blocked, and 1.1.1.1 is not the only encrypted DNS provider.
If whatever DNS you use doesn't work, then you cannot resolve any new domain names until you change to another DNS server or it gets fixed. Recently used domains will be cached in will thus still work.
The post also notes that they won't be using the 1.1.1.1 address, though they'll be using Cloudflare. They'll likely be using another address which is less likely to be blocked.
Could people in heavly-restricted regions, like China and such, access blocked sites if they use DoH to DNS outside the control of the censoring entity?
The censoring entity can still block the IPs of the services, but it's an additional difficulty (unless they're willing to block e.g. all of Cloudfront when someone hosts their website on S3).
They can't block something like domain fronting themselves, have to "ask" companies that host them to help. But they can easily block resolvers by IP, SNI, etc, if not already.
South Korean government censors DNS of North Korean websites. (I think this is stupid and South Korean government should stop immediately.) I tested Firefox DoH implementation and it does circumvent South Korean censorship.
Why would I want my browser to do this? My browser should use the DNS configured by my OS -- in my case, a local, caching resolving NS. If I want to use some kind of DNS-over-HTTP I'll tell my OS to do it. I don't want my browser making DNS decisions for me. What am I missing?
You're missing that you can still configure the browser to your needs? You seem to be a power user so you can do this. Mozilla cares about average users too, and doesn't have control over OS defaults that may not be optimal for average users' privacy.
I, too, have a local caching resolver. And I'm unlikely to turn this on at the browser level, although I'm occasionally tempted to play with it in the resolver.
But I strongly suspect we're in the minority and that something like this is the easiest -- and quite possibly the only -- way for many users to avoid DNS poisoning by ISPs.
I think you missed the point of the parent comment, it wasn't that only ISPs poisoning DNS are impacted it was that this solves that problem for the vast majority who have no clue, excepting those who do the exact thing you describe and understand how to point it at their pi-hole.
That doesn't mean it's suddenly in scope for a browser. The solution would be for the OS to support it, not for the browser to do an end-run around the OS's DNS settings.
>Sure, would be nice for the OS to support it, but until that future point why wait.
Because with the current system I can configure my DNS to my liking at my router and it propagates to all devices. Replacing that with a system where after every Firefox update I have to double check whether Firefox is still doing what I want on all devices is a total pain in the ass by comparison.
You're missing that you're a technically skilled individual, and most browser users are not. The design decisions must cater to the unskilled, because they will not opt in manually. By default most OSes will use their ISP's DNS, and this will very often be insecure and compromised in some way.
Hmm, I have a feeling this feature will be opt out one day.
One more thing to remember to turn off in Firefox, if you're running your own DNS over TLS with more elaborate config than what will be in Firefox.
One thing I like about this DNS over TLS is that now it should be possible to route DNS requests over tor safely to a more trusted DNS resolving endpoint. Though I haven't yet checked how it would work with Cloudflare.
Will I have to solve google captacha per handful of DNS requests if I try to access 1.1.1.1 from tor? Anyone tried?
The real solution is for the captive portal is to signal that there is a captive portal.
Unfortunately that has turned into an arms race: some operating systems switch to a different browser when they detect a captive portal. So captive portals try to avoid detection, etc.
Basically what you want is package that tries to detect a captive portal and when it detects one alerts the user and offer to start a browser that uses the DHCP-supplied DNS resolvers to interact with the portal.
Trying to access any IP directly also typically works, e.g. 8.8.8.8. The redirect to that IP following the login is then of course broken/timing out, but that’s not really a problem.
Because browsers follow a pattern of reinventing the wheel with different tradeoffs, primarily focusing on "secure" execution of untrusted code from the web. Just look at the stack of web technologies, they provide an ever-expanding set of abstractions and reinventions of what OSes already provide.
I think the main reason this happens is because SSL is a pain to configure and develop and it's easier to just use HTTP's SSL than to make an SSL version of everything else.
It wouldn't be my first choice for a lot of reasons, but HTTP2 is getting pretty close to just being a binary protocol anyways.
You can't condone it because you'd prefer "DNS over TLS" or a you have a notion that DNS shouldn't have other headers before it because it's a core protocol and should reimplement the functionality it needs frome TLS?
In the case of the former I agree, the browser should be doing this over TLS as HTTP isn't giving any additional protocol functionality. In the case of the latter the purpose of protocol encapsulation isn't that the most important comes first it's that you can abstract service layers instead of remaking them for each new thing.
I don't see how this improves privacy. Yes, my local ISP, whose DNS I'm using, knows the domains I'm connecting with. They most likely can also access this info in cleartext in other ways, if they care enough. For instance through SNI.
Beyond my ISP, it's doubtful that unencrypted nature of DNS has any impact on my privacy due to heavy caching and the fact that my requests are merged together with requests from many other users.
With DNS over HTTP a single third-party overseas now gets access to this list of domains I'm connecting with. It all just seems like a thinly veiled attempt at more centralization of internet services. Yes, my residential ISP and my coffee shop, library, etc. don't have these "very strong privacy agreements". But I think it's less likely they will all combine their logs to track my behavior than a single centralized entity.
Your ISP is very likely literally selling your DNS data to the highest bidder right now. They don't not have a strong privacy agreement out of laziness, they don't have one because your traffic data is valuable.
It does not improve privacy, it just puts all your DNS history in the hands of one provider. Not only that it adds latency for no real gain. HTTP is a terrible protocol for anything time sensitive. (its a fairly bad protocol for anything fast or efficient full stop.)
The better way to do this is encourage/provide DNSsec (so we know that a provider is who they say they are) and then encrypt dns queries between servers.
Firstly that stops everything being centralised by default, (kinda, DNSSec has a chain of trust, so thats centralised) DNS is a massively scalable fault tolerant, distributed key value store. Far faster and more reliable than toys like Etcd and the like.
secondly you don't then loose geolocation/provider steering for nearest/fastest node. (yes you can get meta data from IP, but that's not really that useful, that means the _service_ has to figure out how to route your request, not the upstream DNS.)
But it needs improvements to make its more anonymous, slapping a fast SSL like tunnel on a resolver combined with DNSsec seems like a much better way to do this and dns over HTTP.
In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.
Doesn't really save you anything; DTLS still involves a connection with a handshake, so you have increased latency and memory overhead. Its usefulness is in low latency transport where head-of-line blocking would be detrimental (e.g. real-time streaming video; phone calls; VPNs).
DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.
DNSCurve requires an out-of-band process for the exchange of key information. This is how it works around the handshake requirement. It's been a while since I read the spec though, so not sure what the current process is.
DNS-over-TLS with a persistent connection to the resolver can be more efficient than UDP-based protocols since you can put multiple queries or answers into one packet. DNS supports pipelined queries and out-of-order responses over TCP and TLS so there isn’t a head-of-line blocking problem.
Firefox has both soft-fail and hard-fail modes.. for a soft fail it will fallback to traditional port 53 DNS. Its likely that will be the most common deployment - you need it to deal with captive portals (i.e. the hotel wifi) and other split horizon issues as well cloud uptime incidents. But there is a hard fail mode if that is suitable for your environment.
I think why Mozilla still doesn't want DNSSEC is because when it breaks it breaks in a big way. And DNSSEC still hasn't got their root key (ksk) rollover process in place. Which is something they would need to properly support to make sure nothing breaks.
On the transport front. Eventually I would expect them to use HTTP/2 over UDP/DTLS which is actually pretty darn efficient. It's the IETF standard based on Google QUIC. Which will probably be called QUIC. Because the IETF workgroup is called QUIC.
I can hear the product managers at cloudflare maniacally laughing their heads off right now.
A side-effect if you're being generous, or primary motive if you're being cynical, of 1.1.1.1 is that CF acquires all the geo info at the expense of everyone else. This puts CF in a particularly advantageous position over DIY GSLB (pushing content providers into using CF), as well as other CDNs of course. Not only that, the privacy policy promises they will not share resolver data with any other party! lol of course they won't -- why would they give up this competitive advantage! It means they are guaranteeing they will not pass on RFC7871 ECS info.
Of course DNS-based geo isn't perfect, and there are other solutions (js pixel timing, anycast, others) but using DNS is still pretty major. Combining it with anycast, as CF does, is surely powerful.
Getting FF to use 1.1.1.1 so that "user's don't have to" is incredible. Someone at CF is getting a huge bonus this year.
“Any data Cloudflare handles as a result of its resolver for Firefox is as a date processor acting pursuant to Firefox’s data processing instructions. Therefore, the data Cloudflare collects and processes pursuant to its agreement with Firefox is not covered by the Cloudflare Privacy Policy. As part of its agreement with Firefox, Cloudflare has agreed to collect only a limited amount of data about the DNS requests that are sent to the Cloudflare Resolver for Firefox via the Firefox browser. Cloudflare will collect only the following information from Firefox users: […] All of the above information will be stored briefly as part of Cloudflare’s temporary logs, and then permanently deleted within 24 hours of Cloudflare’s receipt of such information.”
The reason we (Cloudflare) don't share ECS info is to protect the privacy of the querying user by not exposing their full IP address to the authoritative resolver. We are exploring ways we can pass a subset of this information such that the user can be roughly geolocated without exposing their identity.
Cloudflare runs an Anycast network, we do geographic load balancing by terminating the user's connection at our closest point of presence (as determined by BGP) and then routing their traffic to the origin of the customer's choice from there. As we're not doing geo load balancing using DNS, I'm not sure what the information provided by 1.1.1.1 would do for us.
Imagine if this became the default with only Cloudflare as a provider. Firefox users in countries all over the World will not be able to visit a website locally or anywhere else without asking an American corporation for the IP address first.
I mean. I can't believe that there are going to be a lot of alternative providers. It's going to be an expensive service to provide. Especially when one of the requirements is that you can't mine the data to recuperate costs (and rightly so).
Does Chrome use Google's DNS servers? I've read conflicting information online. Chrome would need to use the local DNS provider to find hosts on your LAN.
I hope they are not making this a default setting.
What about GeoDNS load balancing/routing that a lot of companies are using? Some time ago I've tested Google DNS servers and got worse location from Akamai than using my ISP DNS servers. It was before Google introduced EDNS Client Subnet (rfc7871)[1] so I don't know how things are now but probably biggest CDN providers like Akamai now give exactly the same results as you would use your own ISP DNS servers. I don't know if smaller companies/CDN providers implement it tough.
How cloudflare is solving this with their 1.1.1.1 DNS server? Because if they don't then it can be really problematic for some percentage of users.
It's a balancing act between protecting the privacy of the requesting user and trying to provide enough location information that legacy services know how to route their traffic. We (Cloudflare) will likely begin providing an approximation of the ECS information which tries to strike the right balance.
While this is much better imo than just sending over DNS protocol as eliminates old DNS attacks like spoofing, it won't make users _practically_ any safer since all subsequent TCP requests have the resolved IP in the IP packet. But like I said, it's still better than the default protocol.
The New Cabal of the Web: 1) CloudFlare, 2) Google, 3) Mozilla, 4) Let's Encrypt, 5) a smattering of contributing vendors, 6) internet-related standards bodies, and a few other orgs I'm forgetting or not familiar with. Pretty much the entire WWW is being shaped and controlled by this group. "Open Web" my ass.
The really insane thing to me is that a lot of this tech is being pushed with the argument that they need to get around "port blocking". Uh. These groups setting these new standards run the most critical parts of the WWW, which is the most critical part of the Internet outside of the routing of it. They could get everyone to open up a god damn firewall port if they wanted. I mean this is just ridiculous. There's 65,535 ports and we only get to use one of them (443) because people are too lazy to do anything else?
This is the world we live in. Why can’t I access websites over ipv6 even though they’re hosted on cloud providers with ipv6 support? Because just getting people to change their configuration without an immediate benefit to themselves is arguably the hardest problem for the Internet right now.
Pretty much the entire WWW is being shaped and controlled by this group. "Open Web" my ass.
In reality, "they" couldn't even ship Array.prototype.flatten because a few sites won't update MooTools. What you describe couldn't be further removed from reality.
> They could get everyone to open up a god damn firewall port if they wanted.
No. They couldn’t. That’s the paradox. Together they control the client software running on just about everyone’s computers and phones… but they have very little control or influence over your random IT administrator running a corporate firewall or middleware box, who’s decided to block everything but 80 and 443 for “security” reasons. They don’t even have much influence over the vendors of those devices. Witness Chrome having to roll back TLS 1.3 support after initially deploying it, because BlueCoat and other vendors’ proxies were dropping all TLS 1.3 connections [1], despite TLS 1.3 having been many years in the making, and theoretically bring fully backward-compatible due to making use of the TLS version negotiation mechanism. In that case the relevant vendors did eventually release software updates, but only after Chrome forced their hand by unintentionally breaking all SSL sites for users behind those proxies – including Chrome’s own self-update server, so those users couldn’t even receive the rollback update! I’m sure that’s not an experience Google (or anyone else) is eager to repeat.
Besides, for the sake of privacy, it’s best to limit the information transmitted in cleartext over the Internet to the absolute minimum – and that includes what type of service is being accessed. Why should an adversary intercepting traffic get to learn that for free from the port number, when that information could be transmitted as part of the encrypted connection instead? (Yes, the adversary might be able to figure it out anyway through traffic analysis, but at least that has limits and potential countermeasures.)
I don't buy this line for one minute. The fact that these organizations are either too weak or incompetent to roll out difficult changes in no way means it can't be done. This is just the path of least resistance. Rather than design something good, we just slap a layer of crap on top of another layer of crap and call it an improvement. But dressing up a turd doesn't make it smell like roses.
The fact is that half (if not more) of the world depends on Google, Mozilla and CloudFlare. If they actually committed to breaking networks with a new standard, the vendors and network admins would have no choice but to slowly but surely roll out fixes, because the users need it. Maybe they should actually roll out a product that would update networks to fit an application's needs, like Kubernetes for SDN.
This feature is literally "Oh, we're having problems with DNS, but changing the protocol could be hard, so let's hide a new version of it inside some other protocol." They should stop screwing around and just release a Google Chrome VPN, which you just know they're going to release. AMP was just the amuse bouche.
Let's be real here, an advertising company does not care about privacy. Chrome implemented DNS over HTTPS a long time ago because it was a technical fix for a browser issue, not for privacy. Mozilla was slow to adopt but it got on the bandwagon. And let's not pretend that "hiding" a port number is a security feature, security by obscurity is a joke.
Well, an advertising company doesn't care about protecting your privacy from themselves as the threat. But protecting you from rival data-miners like unscrupulous ISPs could actually help their business model, if you want to look at things cynically.
And protecting DNS queries from local poisoning or outright censorship is the security feature. Having to resort to the 'easy,' non-boat-rocking encryption port of 443 is an implementation detail.
First of all, censorship is censorship. It's not an exploit or a bug, it's a purposeful set of laws, policies or regulations meant to restrict the use of something. DNS over HTTPS "improving security" in a censorship context is the same as saying that when a corporate web proxy prevents you from going to PornHub, circumventing that proxy is "improving security". And btw, circumventing censorship may be illegal, or at the very least against official policies.
It's also not a security feature because you don't need this to protect against cache poisoning, as DNSSEC already does that.
Chrome implemented DNS over HTTPS only three months ago[1], and I don't believe it currently uses it by default (overriding the OS default DNS server choice) like Mozilla is planning to do. The initial IETF draft[2] lists authors from ICANN and Mozilla, not Google.
I'm not sure how it's supposed to work through captive portals. I guess if you can't get to the DNS-over-HTTPS page, use the system resolver? But then networks will just block the DNS-over-HTTPS page implicitly to force the system resolver when they need it.
Another thing this will break: corporate intranet sites. Suddenly you can't browse to your intranet site because Mozilla never checked the DNS server that your computer was assigned by the company.
Yes, you can just block cloudflare-dns.com and this will stop working. As the article mentions, Firefox will fall back to normal DNS unless you set a hard-fail flag.
[Edit: firefox says they're using a different endpoint, but I'm assuming you can just block that too.]
Corporate intranets are used to configuring user desktops already. This is just another switch to flip.
I don't understand why everyone is so down on this. I see this as a big win for average non-techie computer users in terms of privacy. Unlike many of us here, they're not going to take the time to set up a resolver or even click a checkbox hidden in preferences. Someone needs to take the first step in making encrypted DNS on _by default_. Once more people use it, other organizations that are in a more ideal position will follow and improve on it.
125 comments
[ 3.1 ms ] story [ 222 ms ] threadhttps://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...
Sophisticated users run their own resolvers instead of relying on unverifiable promises from for-profit entities.
For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view.
Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale.
Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol.
There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale.
At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.
For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare.
For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers.
At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.
It still means that your ISP or a wiretap on your own internet pipe can check your browsing activity by monitoring SNI's, but then again, they can also figure that out for a lot of sites by just checking the IP.
Then you could argue that all sites should use CDNs to hide this, but then you open the argument of whether the internet should be centralized or decentralized.
Encrypted SNI would be nice, but are tricky (wouldn't work well in multi-tenant setups), and those that can sniff the SNI probably know where you were going anyway.
I'm sure SNI is next on the list, it will just take a bit longer. Until then, let's harden other parts of the infrastructure.
If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do. Bob has no way to know I'm even trying to contact him, so he can't help.
You can tell a few people near you that "someone" wants to tell something to Bob and an answer from Bob. They tell people near them and so on, until it reaches Bob. He then answers and tells people near him, they tell those who told them and so on, until the answer is delivered back to you. And since no one can hear what people tell each other, no one can assume that "someone" is you and not someone else talking to you in secrecy, many connections away from you.
Think overlay peer-to-peer networks.
But the minimum viable threat model is ISP appliances that do classification and identification of traffic, both passively and actively, like trying to probe for protocols and hostnames. If you are not targeting them, you are effectively doing nothing, but pretend privacy PR. Which is the case with Cloudflare's DNS.
Sure, scaling is harder, but it's not impossible.
If you decide well that's OK, we can do something simpler - everybody will have an infinite set of aliases like "Zanizabo" or "Fylnatis" but they won't be one-to-one shared secrets, alas Mallory simply hears you say "Zanizabo" and she says "Hey, Zanizabo, call Oxymoron" (Oxymoron is an alias Mallory has chosen for this purpose) and soon discovers that Bob answers so now she knows who you wanted to talk to.
That's not the problem though. You're not trying to stop an eavesdropper knowing you're communicating with a particular server, but rather which hostname you're talking to them as.
To extend the Bob analogy; you're not trying to hide that you're communicating with Bob, but that you're speaking to each other as members of Fight Club.
It's certainly not impossible, although overcoming issues of scaling or increased handshake round trips is a difficulty.
In order to be sure we're talking to Bob, so that it's OK if Bob knows we want his Fight Club certificate, I think we have to incur an extra round trip while we obtain the proof he's Bob and send back the request for Fight Club.
If we try to skip that step, Mallory simply interposes, we send our message to Mallory, believing she is Bob, and she reads it to determine we want Fight Club, we are undone. So we have to wait until Bob proves his identity, and only then reveal that we wanted Fight Club.
Of course, this approach would require the DNS record is authenticated, so DNSSEC is a must, added to which the DNS resolution must be encrypted, so DNS over HTTPS, DNSCurve, etc.
Two small problems I will mention, one of which I'm sure you already know: First, encrypted DNS and DNSSEC are not yet widely deployed, so this isn't the silver bullet many people expected of Encrypted SNI.
Second, for an endpoint which has many unrelated names and certificates - which is the case where encrypted SNI is gaining us a clear security benefit given our packets must have a plaintext IP destination - now they need to try every possible private key to see if they can open our encrypted SNI. This might be a very considerable burden.
The idea was to have a single common introductory keypair which all tenants publish to their DNS, in order to encrypt the SNI. That way there is no need to try multiple private keys.
The lack of DNSSEC deployment is an issue, although there's nothing to stop such schemes being employed on an opportunistic basis. However, when DNSSEC is available for a domain, the scheme should be enforced to prevent a MITM attack.
Create a key out of nowhere for 2 parties to boot strap communicate safely. (obviously Diffie-Hellman doesn't solve all problems like knowing who you are actually talking to)
TLS 1.3 also encrypts the server certificate. So if you want to send bonus SNI but get back real certificates that's just a matter between client and server.
The use case for Encrypted SNI remains sketchy. If I am the secret police of some authoritarian nation, who would block diebartdie.example why wouldn't I instead block the IP addresses of servers offering diebartdie.example? Only because it causes collateral damage? But why do I care, teach them not to associate with my enemies.
Because the collateral damage may not be worth it. The website a handful of dissidents use may not be worth blocking everything running on Cloudflare for all your citizens, for instance.
...which is sometimes very desirable[1][2][3]. I get the whole "more security!" movement, but also feel like it's just contributing to turning general-purpose computers into locked-down media consumption devices.
[1] https://pi-hole.net/
[2] https://en.wikipedia.org/wiki/Proxomitron
[3] https://news.ycombinator.com/item?id=17196888
More generally, more security does not stop any legitimate use-cases. You just chose to extend your trust.
#3 doesn't have anything to do with the subject at hand.
Network interception is never something a user wants, and does not implement additional security. It's common in enterprise and banking environments for all the wrong reasons (enough that these industries were trying to harm TLS1.3 when they realized that the increased security was troublesome). Such a setup is by no means necessary, and due to there being Bad People in this world, the ability to do so is dangerous.
Repressive governments that wish to control or manipulate information is a very good example, and sacrificing silly enterprise politics is a very small price to pay to help the repressed. The result of There are quite a few places where this is the case, even though it might be hard to imagine for someone in the west (despite filtering occurring in the west too, whenever the government dislikes a site).
You can use it to connect to Cloudflare or other DoH servers, and this will not be limited to queries sent by Firefox.
On iOS, use DNSCloak.
Adding an authentication header prevents alteration but it does not present a viable option to the problem statement.
Making this a default means that Firefox users all bypass censorship in several countries, what do they expect to happen as a result of it? Firefox blocked? 1.1.1.1 blocked?
If whatever DNS you use doesn't work, then you cannot resolve any new domain names until you change to another DNS server or it gets fixed. Recently used domains will be cached in will thus still work.
Except for the many domains that set very low TTLs for load balancing and cloudiness reasons.
Your actual privacy is of secondary concern.
But I strongly suspect we're in the minority and that something like this is the easiest -- and quite possibly the only -- way for many users to avoid DNS poisoning by ISPs.
Sure, would be nice for the OS to support it, but until that future point why wait.
Because with the current system I can configure my DNS to my liking at my router and it propagates to all devices. Replacing that with a system where after every Firefox update I have to double check whether Firefox is still doing what I want on all devices is a total pain in the ass by comparison.
One more thing to remember to turn off in Firefox, if you're running your own DNS over TLS with more elaborate config than what will be in Firefox.
One thing I like about this DNS over TLS is that now it should be possible to route DNS requests over tor safely to a more trusted DNS resolving endpoint. Though I haven't yet checked how it would work with Cloudflare.
Will I have to solve google captacha per handful of DNS requests if I try to access 1.1.1.1 from tor? Anyone tried?
What's the way to circumvent this problem? I'm frequently on public wifi's, so I need to access AP login pages without issue.
Unfortunately that has turned into an arms race: some operating systems switch to a different browser when they detect a captive portal. So captive portals try to avoid detection, etc.
Basically what you want is package that tries to detect a captive portal and when it detects one alerts the user and offer to start a browser that uses the DHCP-supplied DNS resolvers to interact with the portal.
Yet another step closer to HTTP/IP, I guess. Can’t say I condone it.
It wouldn't be my first choice for a lot of reasons, but HTTP2 is getting pretty close to just being a binary protocol anyways.
In the case of the former I agree, the browser should be doing this over TLS as HTTP isn't giving any additional protocol functionality. In the case of the latter the purpose of protocol encapsulation isn't that the most important comes first it's that you can abstract service layers instead of remaking them for each new thing.
Beyond my ISP, it's doubtful that unencrypted nature of DNS has any impact on my privacy due to heavy caching and the fact that my requests are merged together with requests from many other users.
With DNS over HTTP a single third-party overseas now gets access to this list of domains I'm connecting with. It all just seems like a thinly veiled attempt at more centralization of internet services. Yes, my residential ISP and my coffee shop, library, etc. don't have these "very strong privacy agreements". But I think it's less likely they will all combine their logs to track my behavior than a single centralized entity.
Note that "your local ISP" means "whatever coffeeshop you are using wifi in", for laptop users, right?
You're right that if the resolver decides to keep and correlate logs that's bad. It's pretty key to use a resolver that you trust to not do that...
It does not improve privacy, it just puts all your DNS history in the hands of one provider. Not only that it adds latency for no real gain. HTTP is a terrible protocol for anything time sensitive. (its a fairly bad protocol for anything fast or efficient full stop.)
The better way to do this is encourage/provide DNSsec (so we know that a provider is who they say they are) and then encrypt dns queries between servers.
Firstly that stops everything being centralised by default, (kinda, DNSSec has a chain of trust, so thats centralised) DNS is a massively scalable fault tolerant, distributed key value store. Far faster and more reliable than toys like Etcd and the like.
secondly you don't then loose geolocation/provider steering for nearest/fastest node. (yes you can get meta data from IP, but that's not really that useful, that means the _service_ has to figure out how to route your request, not the upstream DNS.)
But it needs improvements to make its more anonymous, slapping a fast SSL like tunnel on a resolver combined with DNSsec seems like a much better way to do this and dns over HTTP.
DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.
The more paranoid (or prudent, depending on your perspective) among us would run their own DNS resolvers.
On the transport front. Eventually I would expect them to use HTTP/2 over UDP/DTLS which is actually pretty darn efficient. It's the IETF standard based on Google QUIC. Which will probably be called QUIC. Because the IETF workgroup is called QUIC.
A side-effect if you're being generous, or primary motive if you're being cynical, of 1.1.1.1 is that CF acquires all the geo info at the expense of everyone else. This puts CF in a particularly advantageous position over DIY GSLB (pushing content providers into using CF), as well as other CDNs of course. Not only that, the privacy policy promises they will not share resolver data with any other party! lol of course they won't -- why would they give up this competitive advantage! It means they are guaranteeing they will not pass on RFC7871 ECS info.
Of course DNS-based geo isn't perfect, and there are other solutions (js pixel timing, anycast, others) but using DNS is still pretty major. Combining it with anycast, as CF does, is surely powerful.
Getting FF to use 1.1.1.1 so that "user's don't have to" is incredible. Someone at CF is getting a huge bonus this year.
“Any data Cloudflare handles as a result of its resolver for Firefox is as a date processor acting pursuant to Firefox’s data processing instructions. Therefore, the data Cloudflare collects and processes pursuant to its agreement with Firefox is not covered by the Cloudflare Privacy Policy. As part of its agreement with Firefox, Cloudflare has agreed to collect only a limited amount of data about the DNS requests that are sent to the Cloudflare Resolver for Firefox via the Firefox browser. Cloudflare will collect only the following information from Firefox users: […] All of the above information will be stored briefly as part of Cloudflare’s temporary logs, and then permanently deleted within 24 hours of Cloudflare’s receipt of such information.”
source: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
Is this Firefox specific (via HTTP headers or EDNS options) or is this just the general policy of the 1.1.1.1 resolver for all users?
Edit: according to https://www.cloudflare.com/privacypolicy/ the normal privacy policy applies to users of CloudFlare's DNS.
Cloudflare runs an Anycast network, we do geographic load balancing by terminating the user's connection at our closest point of presence (as determined by BGP) and then routing their traffic to the origin of the customer's choice from there. As we're not doing geo load balancing using DNS, I'm not sure what the information provided by 1.1.1.1 would do for us.
I mean. I can't believe that there are going to be a lot of alternative providers. It's going to be an expensive service to provide. Especially when one of the requirements is that you can't mine the data to recuperate costs (and rightly so).
How cloudflare is solving this with their 1.1.1.1 DNS server? Because if they don't then it can be really problematic for some percentage of users.
[1] https://tools.ietf.org/html/rfc7871
The really insane thing to me is that a lot of this tech is being pushed with the argument that they need to get around "port blocking". Uh. These groups setting these new standards run the most critical parts of the WWW, which is the most critical part of the Internet outside of the routing of it. They could get everyone to open up a god damn firewall port if they wanted. I mean this is just ridiculous. There's 65,535 ports and we only get to use one of them (443) because people are too lazy to do anything else?
In reality, "they" couldn't even ship Array.prototype.flatten because a few sites won't update MooTools. What you describe couldn't be further removed from reality.
https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
No. They couldn’t. That’s the paradox. Together they control the client software running on just about everyone’s computers and phones… but they have very little control or influence over your random IT administrator running a corporate firewall or middleware box, who’s decided to block everything but 80 and 443 for “security” reasons. They don’t even have much influence over the vendors of those devices. Witness Chrome having to roll back TLS 1.3 support after initially deploying it, because BlueCoat and other vendors’ proxies were dropping all TLS 1.3 connections [1], despite TLS 1.3 having been many years in the making, and theoretically bring fully backward-compatible due to making use of the TLS version negotiation mechanism. In that case the relevant vendors did eventually release software updates, but only after Chrome forced their hand by unintentionally breaking all SSL sites for users behind those proxies – including Chrome’s own self-update server, so those users couldn’t even receive the rollback update! I’m sure that’s not an experience Google (or anyone else) is eager to repeat.
Besides, for the sake of privacy, it’s best to limit the information transmitted in cleartext over the Internet to the absolute minimum – and that includes what type of service is being accessed. Why should an adversary intercepting traffic get to learn that for free from the port number, when that information could be transmitted as part of the encrypted connection instead? (Yes, the adversary might be able to figure it out anyway through traffic analysis, but at least that has limits and potential countermeasures.)
[1] http://web.archive.org/web/20170311013249/https://bugs.chrom...
The fact is that half (if not more) of the world depends on Google, Mozilla and CloudFlare. If they actually committed to breaking networks with a new standard, the vendors and network admins would have no choice but to slowly but surely roll out fixes, because the users need it. Maybe they should actually roll out a product that would update networks to fit an application's needs, like Kubernetes for SDN.
This feature is literally "Oh, we're having problems with DNS, but changing the protocol could be hard, so let's hide a new version of it inside some other protocol." They should stop screwing around and just release a Google Chrome VPN, which you just know they're going to release. AMP was just the amuse bouche.
Let's be real here, an advertising company does not care about privacy. Chrome implemented DNS over HTTPS a long time ago because it was a technical fix for a browser issue, not for privacy. Mozilla was slow to adopt but it got on the bandwagon. And let's not pretend that "hiding" a port number is a security feature, security by obscurity is a joke.
And protecting DNS queries from local poisoning or outright censorship is the security feature. Having to resort to the 'easy,' non-boat-rocking encryption port of 443 is an implementation detail.
It's also not a security feature because you don't need this to protect against cache poisoning, as DNSSEC already does that.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=799753
[2] https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-01
Another thing this will break: corporate intranet sites. Suddenly you can't browse to your intranet site because Mozilla never checked the DNS server that your computer was assigned by the company.
[Edit: firefox says they're using a different endpoint, but I'm assuming you can just block that too.]
Corporate intranets are used to configuring user desktops already. This is just another switch to flip.