What is this new DNS protocol being pushed by Mozilla and Google, and what does it have to do with anti-trust laws?
The Internet, back when it started as ARPANet, didn’t think there would be all these bad people doing bad things. The whole idea was to share … everything.
So a lack of security for key things wasn’t baked in and once things took off and the need for such security was clearly needed it was very difficult to add the right tools.
With DNS, anyone on the route between you and your DNS provider can see what sites you are looking up. Needless to say, this can be very revealing. So ISPs, for example, like to collect and sell that info. And with people roaming around and using WiFi hotspots there’s a host of others interested in snooping on you.
Furthermore, some ISPs like to block certain sites. So they block not just DNS requests to such sites on their own DNS servers, but when trying to access other DNS servers like Google’s.
So along comes DNS over HTTPS. The DNS request is encrypted and sent via HTTP which ISP’s can’t snoop on nor block wholesale. Now, they will know that you are accessing a web site that does DNS lookup. But they can’t tell what sites you are looking up. And blocking Google’s DNS-over-HTTP site entirely would not go over well.
But note: Now Google, for example, is collecting your DNS look up info. Again, valuable. And since most people will be using Google’s service, this is again more money, control, etc. for Google. That’s something to worry about.
Other factors: In the UK there’s a bunch of laws restricting access to adult web sites and such. So the ISPs are forced to be heavy handed. DNS-over-HTTPS helps bypass some of this. So the Firefox (Mozilla) people have just promised the UK that it won’t be turned on by default. Mozilla is a small time group and can’t waste energy fighting it. OTOH, users will still be able to easily turn it on.
One thing to keep in mind: if someone is running a DNS-over-HTTPS server they aren’t doing it out of the goodness of their heart. These things take money to run and so they will be looking for a way to monetize it. Guess what they are going to sell to pay for it?
Yeah, Google’s “Don’t be evil.” motto went down the drain many years ago. But there’s no guarantee that if Google didn’t do it, other even worse companies would be in control of the market.
I’m trying to wrap my head around this.
Let’s say I’m in a café with public wifi, and my phone is connected over that wifi. In all likeliness the wifi router gives me an IP address for a DNS server provided by their ISP. I tell my browser to connect to https://boards.straightdope.com. The browser tells the phone to communicate with the public wifi router, and first it asks “please ask [DNS Server IP] what is the IP for boards.straightdope.com?” Anybody within range of my laptop can overhear this communication. The router takes this message and sends it down a physical line to the ISP, who patches it through to the DNS server I specified. That’s where law enforcement or particularly bad actors can put a wiretap. The DNS server has a listing of domain names to IP addresses, or at least knows which other DNS servers to ask, performs the translation from “boards.straightdope.com” to “35.190.42.236”, and sends that back through the ISP to the café router. The router then announces over the air, “Max’s Phone, [DNS Server IP] has responded that boards.straightdope.com goes by 35.190.42.236”. Anybody within range can overhear that response. My phone then shouts over the open air, “router, please tell 35.190.42.236:443 I would like to establish a secure connection”. Anybody within range can hear this, too. The router forwards this message to the ISP which forwards it across the country (and other ISP networks) to the Straight Dope’s server in California. The SDMB server responds through their ISP and after a couple back and forths a secure connection is established. Anybody can overhear the communications between my phone and the router, but due to the difficulty of prime factorization it is virtually impossible to guess the secret key established (but never explicitly mentioned) during the handshake. My phone uses this shared secret key to send an encrypted HTTP GET request, and the SDMB responds with an encrypted webpage that my browser renders and I get to see. People can overhear the encrypted message, but without the key they cannot make sense of it. Time elapsed: 400ms.
Now this DNS over HTTPS, as I understand it, means my phone will first try to do that TLS handshake with the DNS server. So the first message is from my phone to the router, over the open air: “please tell [DNS Server IP] that I would like to start a TLS connection”. My phone and the DNS server effectively communicate over the open air (in the café) to establish a shared secret keycode without actually saying the code or letting anybody else guess it. Then my phone sends an encrypted message asking what the IP is for boards.straightdope.com. The response comes back in an encrypted message, and nobody within range can tell what I asked for or what I recieved.
But then, when I want to establish a secure connection with the SDMB, don’t I shout that same IP address over the open air? “Please connect me with 35.190.42.236:443!” All of that safeguarding for naught, it would seem; anyone within range would be able to tell that I connected to 35.190.42.236.
I suppose there is a little bit of information protected. I suppose webservers that host multiple sites will serve certain sites based on HTTP headers, which are encrypted if I use HTTPS. That means a snooper in the café will only know that I connected to this one webserver. They won’t know which individual site I actually connected to.
Well, that’s my understanding now that I’ve had some time to look into it. Let me know if I’m wrong or if you know what this has to do with anti-trust.
~Max
Yeah, that’s basically the size of it. For the most part, no one outside of the local connection from you to the local caching DNS server can snoop your DNS lookups - the rest of the world can only see that the cafe’s caching DNS server (which is probably also used by other customers) did the DNS lookups on your behalf.
I’m still on the fence on whether I like this scheme a whole lot. If it was widely adopted as a replacement for normal DNS (say the first DNS lookup was just to find the list of current ISP’s DNS over HTTP servers), then I’d feel a lot better about it. It being centralized at Google just seems too ripe for abuse and attack.
But as far as utility goes, after receiving the IP address over an encrypted channel, don’t we just blurt it out in the open? Could not a potential snooper simply do a reverse-DNS search?
Is Google somehow attempting to monopolize the domain name system? Do they have patents on DNS-over-HTTPS server technology or something?
~Max
DNS over HTTPS is an official IETF RFC 8484
Seems to be a purely good thing if every DNS used this??
If Google (Chrome / Services) bypasses the normal resolver and always goes to its own Nameserver then I can vaguely see competition problems but that has to be addressed separately.
Regarding hiding DNS when using public WiFi:
Good news, all your data is encrypted over WiFi.
Bad news, all you need is the WiFi password to decrypt it. Which is hardly a secret. Esp. to the WiFi provider.
Note that a single IP address can map to several web servers at that address using virtual web servers. So an IP address alone doesn’t necessarily tell you the name of the server at that address. But still there’s a lot of info that can be extracted, etc.
So it’s a far from perfect system but there is some stuff going on that makes it a bit harder to watch you.
Since I posted, Slashdot has done another blurb addressing this matter and the anti-trust issue. I find the quote “… investigators are worried this would give the internet giant an unfair advantage by denying access to users’ data.”
Yeah, we have to have the “right” people selling my data. As opposed to, say no one selling my data which is apparently something the government isn’t interested in.
Yeah, and how about this quote: “Internet service providers are worried that they may be shut out of the data and won’t know as much about their customers’ traffic patterns. This could “foreclose competition in advertising and other industries,” an alliance of ISPs told Congress in a September 19th letter…”
The concern isn’t even true. All ISPs offer DNS to their customers as part of their service. Whenever you connect to an ISP you get a DNS address(es) to use for name resolution. Very few customers overrule these settings. So nothing will change for ISPs.
They won’t get to eavesdrop any more on those few customers that choose to configure their own Nameserver. But that’s a completely unjustified complaint about a small subset of customers.
Google might prevent them from eavesdropping on any traffic involving Google’s products and services. Like I said, that might have to be addressed as an anti-competitive practice.
Customers preventing ISPs from eavesdropping by choice, and now having easier means of preventing ISPs from eavesdropping is not anti-competitive and not a bad thing in any way.
Well, you have the IP, but a single IP can and often does serve out content for more than one domain. Looking up the PTR record of the IP address can give you that, but often doesn’t. For instance, the PTR of the board right now is:
236.42.190.35.bc.googleusercontent.com
Ehh, I’d say they’re trying to get in the game early and have folks get used to using their service so they can dominate it later and add it to their knowledge of what you’re doing.
Kind of. I don’t think your concerns are misplaced, but it’s not true that the WiFi password will decrypt all traffic.
While plenty of cafés and other businesses don’t encrypt their customer-facing WiFi, those that do overwhelmingly use WPA2. WPA2 generates separate keys for each individual client (unicast keys) and an additional pair shared by all clients for broadcast data. See here:
So other wireless clients on the same network are unable to sniff your DNS lookups unless they crack your session key (PMK), which is nontrivial to casual attackers. It’s likely much easier to brute-force the router password in most situations, which is more valuable anyway.
A cracked router would expose all your WPA2-encrypted data (data-link layer, AKA OSI layer 2) to an attacker. However, anything remotely important (and most unimportant data) is encrypted at the transport layer (OSI layer 4) or higher. So even a cracked WiFi router doesn’t do much to help an attacker sniff the auth credentials you use when you log into your bank account. I mean, a cracked router doesn’t hurt an attacker, but your session WiFi keys are hardly the keys to the castle.
DNS queries are a notable exception to this—they’re in plaintext by default, and a cracked router is a great place to monitor DNS lookups. I don’t think this is a big threat for me personally, but encrypting DNS requests is a good idea in general.
A possibly-germane tidbit:
Back in the early aughts, I worked at a network security firm that specialized in firewalls for community banks. We had humans reading each firewall’s logs every day, and those logs included all downloads (http, ftp, etc). Most people would be shocked at what gets downloaded, even at work: tons of porn, including some really edgy stuff like zoophilia videos. Either community bankers are a bunch of freaks (possible) or we’re all a bunch of freaks (more likely). Our policy, naturally, was to report immediately any child porn downloads, but I’m not aware of that happening in the three years I worked there.
I understand why privacy-sensitive people want to hide their DNS lookups, but if your concern is that someone might find out what porn you watch, well, they already know. Odds are that your preferences are wholly unremarkable.
Google’s motto was down the drain as soon as they formulated it. Why on earth would you make a huge point of telling people you aren’t evil… unless you actually ARE evil?
I guess the question is - how is the browser configured?
As I understand it, regular DNS under Windows is (for now) not affected. Just your browser (Chrome, Mozilla) has a special configuration where, instead fo asking Windows to look up and address from a DNS name, it takes it upon itself under this new configuration - it connects to the DNS server it knows that is set up to respond to Encrypted DNS or DNS over HTTPS and then asks that server for the IP address. The $64,000 question then is - can you designate that DNS server or is it locked into the specific choice of the authors of the software? Does this mean all Chrome browsing is going to be done with Google’s DNS in future?
I thought Google Chrome would ship with a list of known DNS-over-HTTPS capable servers, then if the operating system defined DNS server is on the list, it will encrypt the lookup; if not, it will revert to DNS-over-plaintext.
~Max
McKinnon, J & McMillan, R. (2019, September 29). Google Draws House Antitrust Scrutiny of Internet Protocol. The Wall Street Journal. Retrieved September 30, 2019 from https://www.wsj.com/articles/google-draws-house-antitrust-scrutiny-of-internet-protocol-11569765637
Google’s DNS-Over-TLS Plans Scrutinized By US Congress
I object to that generalization. 8-} It’s like saying “all fast food joints use frozen beef” - maybe most do, but not all do. At my ISP (and it actually is my ISP - I’m a co-owner) we don’t sell that info. We do log all queries, but that is for the sole purpose of producing nightly reports to see how we’re doing, and to find misconfigured customer systems (for example, one asking for the address of example.com several times a second all day long). After the nightly analysis, the logs are discarded.
Our customers don’t have to use our DNS servers and we don’t filter any traffic at all on our backbone - a customer router might have specific policies requested by that customer, but once it hits our backbone it is valid traffic, period. However, most of our customers do use our name servers because they’re fast and well-connected (currently, 40Gigabit Ethernet, and 2 of them are on the same LANs as F-ROOT instances).
We would consider it a cost of doing business, just as we’ve upgraded our nameserver hardware many, many times since we started this business back in 1993 when a T1 was considered very fast. Having said that, we’ll adopt a wait-and-see attitude to see a) how prevalent adoption of DoH is and b) whether browser authors make it easy to configure non-default servers (for example, for a customer of ours with hundreds of Windows systems, it would need to be pushable as a group policy update) - if users are stuck with the server(s) baked into the browser, there’s no point in doing it.
Personally, I don’t like it, but for technical reasons. First, it takes something which is normally a single-packet UDP query and a single-packet UDP response and turns it into a whole crypto handshake, cipher negotiation, etc. before things get around to actually passing the query and response. Web traffic is going in the opposite direction with things like HTTP/2 keeping an encrypted connection open and having the server pre-push content it knows the client will need. Second, because HTTPS crypto is a continually moving target with protocols being removed (I’m sure most users have run into that sort of error when web browsing) and the requirements for SSL certificates becoming more stringent (no more 3-year certificates, CA must have a working CRL, etc.)
So the follow-on question would be - can you add to that list?
But some do. Plus, some countries - even ones we once thought of as civilized, like Britain - are trying to mandate that ISP’s block certain sites. Note too that if you combine this tech with a VPN then none of your traffic is exposed to the prying eyes of local providers.
There is an article today on Techdirt discussing this exact thing.
These are my highlights from the article:
The antitrust/monopoly reaction to DNS over HTTPS (DoH) is a false narrative put out by the large telecoms (AT&T, Verizon, Comcast, etc.) to undermine user privacy. Google has always been “lukewarm” on DoH, and has no intention of locking Chrome and Android users into Google’s DoH servers.
There is absolutely nothing stopping the large telecoms from running their own DoH servers, which would allow them to continue to see what DNS requests their users are making. [The only difference is that with traditional DNS, the telecoms can observe any DNS request that transits their network, but with DoH they will only be able to see DNS requests that terminate on their own servers.]
Done correctly, DoH improves user privacy because it prevents anybody except the DoH server operator from knowing what DNS requests users are making. For example, if you set your home DNS provider to Cloudflare, then your ISP (probably AT&T, Verizon, or Comcast) still know what sites you are requesting. If that DNS connection is encrypted, then they do not know. All they know is you are making https requests to Cloudflare, AWS, Azure, Google, and other cloud services.
I have read that it is actually Mozilla who plans on overriding the operating system’s DNS server and connecting to Cloudflare. That might be worrisome, but I don’t think Firefox has the market share to trigger anti-trust regulators…
md2000 raised a good question. My understanding is that Google Chrome will determine which DNS servers support DNS-over-HTTPS by checking their IP address against a list. With Chrome’s market share I would want that default list to be very open for service providers to add their own servers. If the list is just a bunch of Google DoH servers, that wouldn’t be cool.
These remind me of the bundling of Internet Explorer with Microsoft Windows. Even if users can install different browsers or change DNS servers manually, default options matter.
And then if what I read about Mozilla is true, Firefox would by default prevent users from using the ISP’s DNS servers. But I don’t think Mozilla and Cloudflare have common ownership, and I am sure Firefox has an option somewhere to enable DoH using a custom DNS server.
Well, unless you use an encrypted proxy/VPN the ISP also knows the IP address of every other connection you make.
~Max