
Improving DNS Privacy in Firefox - Vinnl
https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/
======
KaiserPro
No, no no and no.

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.

~~~
jiveturkey
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.

~~~
r-w
Please do your research.

“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...](https://developers.cloudflare.com/1.1.1.1/commitment-to-
privacy/privacy-policy/firefox/)

~~~
bluejekyll
> ... DNS requests that are sent to the Cloudflare Resolver for Firefox via
> the Firefox browser.

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?

~~~
sp332
The original article says they're not using CloudFlare's normal DNS-over-HTTPS
endpoint, so this is probably specific to Firefox.

Edit: according to
[https://www.cloudflare.com/privacypolicy/](https://www.cloudflare.com/privacypolicy/)
the normal privacy policy applies to users of CloudFlare's DNS.

------
Tharkun
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?

~~~
LudoA
I used this at some point on my Fedora laptop. I had issues on some hotel APs
where it didn't allow me to see the 'login page' of the AP.

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.

~~~
phicoh
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.

------
peterwwillis
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?

~~~
comex
> 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.)

[1]
[http://web.archive.org/web/20170311013249/https://bugs.chrom...](http://web.archive.org/web/20170311013249/https://bugs.chromium.org/p/chromium/issues/detail?id=694593)

~~~
peterwwillis
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.

~~~
crunchatized
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.

~~~
peterwwillis
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.

------
Vinnl
Related: A cartoon intro to DNS over HTTPS.

[https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-
ove...](https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)

~~~
jwilk
On HN:
[https://news.ycombinator.com/item?id=17196415](https://news.ycombinator.com/item?id=17196415)

------
mike-cardwell
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).

~~~
Lennie
Google will be an other, I would expect. Google is working on this standard to
build it into Android.

------
gnode
There seems to be little point of doing this, in my opinion, when SNI doesn't
secure the hostname.

~~~
st3fan
You have to start somewhere. Security is the sum of all parts. This is a small
part, but it may have a big impact already.

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.

~~~
tialaramex
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.

~~~
gnode
> 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.

~~~
tialaramex
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.

~~~
gnode
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.

~~~
tialaramex
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.

~~~
gnode
> 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.

------
avian
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.

~~~
bzbarsky
There are plans to remove the SNI privacy leak as well.

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...

------
Seipaho8
> While sophisticated users can turn to cloud-based “open resolvers”

Sophisticated users run their own resolvers instead of relying on unverifiable
promises from for-profit entities.

~~~
zamadatix
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.

~~~
Seipaho8
The point is that they are not a single central entity easily siphoned off by
an org that'll sell the information for profit.

------
josteink
Core internet protocols like DNS over HTTP?

Yet another step closer to HTTP/IP, I guess. Can’t say I condone it.

~~~
sanxiyn
There is also DNS over TLS. DNS over HTTPS is basically DNS over TLS, but with
workaround for port blocking.

~~~
Lennie
With eventually a plan to allow for HTTP-caching, use of CDNs, pushing updates
over HTTP/2 push, running it over QUIC, etc.

------
jonnytran
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.

------
OptionX
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?

~~~
majewsky
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).

~~~
zzzcpan
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.

------
rajadigopula
DNSCrypt is also a viable option. -
[https://dnscrypt.info/](https://dnscrypt.info/)

~~~
jedisct1
dnscrypt-proxy also supports DNS-over-HTTPS and is probably the most popular
DoH client.

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.

~~~
rajadigopula
AdGuard app on android also allows dnscrypt to route all the phone
communications go through the dns crypt servers encrypted without rooting.

------
lossolo
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.

[1] [https://tools.ietf.org/html/rfc7871](https://tools.ietf.org/html/rfc7871)

~~~
zackbloom
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.

------
peterwwillis
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.

~~~
sp332
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.

------
myf01d
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.

------
Bromskloss
Wait, aren't DNS lookups done by the operating system?

------
nbsd4life
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?

~~~
AlphaWeaver
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.

~~~
Operyl
Most likely because 1.1.1.1 still doesn't work on networks like AT&T.

------
userbinator
_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] [https://pi-hole.net/](https://pi-hole.net/)

[2]
[https://en.wikipedia.org/wiki/Proxomitron](https://en.wikipedia.org/wiki/Proxomitron)

[3]
[https://news.ycombinator.com/item?id=17196888](https://news.ycombinator.com/item?id=17196888)

~~~
arghwhat
#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).

