Improving DNS Privacy in Firefox
blog.nightly.mozilla.org
blog.nightly.mozilla.org
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.
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.
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
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...
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).
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.
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...
Sophisticated users run their own resolvers instead of relying on unverifiable promises from for-profit entities.
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.
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.
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.
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.
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.
...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.
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).