Chrome devs tell world that DNS over HTTPS won't open the floodgates of hell Chrome devs have had a little rant about "misinformation", repeating that DNS-over-HTTPS (DoH) will be supported but won't necessarily be automatically used in upcoming builds of the browser. In a blog post published last night, Google's Chrome product manager insisted it was not going to "force users to change their DNS …
"Malicious applications and scripts are unlikely to be so accommodating."
In which case you're already screwed as they're probably not using DNS in any event. It's not like this uses any kind of new technology. DNS tunnelling and hardcoded IP lists have been a thing for years (thus why you can't easily block Windows 10's telemetry--it doesn't use DNS).
IOW, anyone who doesn't want to use DNS can do what you say already.
(thus why you can't easily block Windows 10's telemetry--it doesn't use DNS).
Bits of it do. Various MS telemetry domains appear at the top of my Pi-Hole's "most blocked" list.
As you say though, they tend to fall back to hardcoded IPs if the domain doesn't resolve and some elements just use IPs by default anyway.
If an adversary isn't using domain names, that makes blocking them even easier, as I can simply block the IP addresses directly. Attackers typically use domain names rather than raw IP addresses to avoid such trivial blocking. This is especially true when the attackers are advertiser-related.
UNLESS the adversary is using a multi-homed IP address and using a way other than SNI to get through to the actual server versus what normally is there. Until encrypted SNI becomes the norm, a DoH lookup still results in a connection and a sniffable SNI packet. Once eSNI is the norm, or the client uses another system to say which server to serve, you'll need to find another way.
Sure.
I feel the need to be more clear about my stance with DoH. I am not saying that it's without security value. It certainly has that. However, it also comes with a security cost, just from a different direction. For my purposes, the cost is greater than the value, and so I am very concerned that it presents a security hole that I cannot plug without engaging in extreme countermeasures.
All that said, there is no panacea here, whether DoH is used or not. Security is a perpetual game of give-and-take and requires constant vigilance and adjustment of defenses.
Problem is, you're on the defensive end of a siege. Long-term, sieges always favor the attackers because, unlike you, they can work outside the box to find a way no amount of planning can stop. An end-to-end-encrypted link using a key you can't discover seems to be the equivalent of dealing with an adversary able to tunnel through bedrock.
That is the problem. I have a Pi-Hole, which blocks around 2.5 million tracking, malware and malvertising sites, including all Facebook properties.
But my Fire tablet insisted on using its own DNS server, ignoring my local settings. I had to manually re-configure the settings to force it to use the DNS server it was told to use by DHCP.
The situation will only get worse, when individual applications start ignoring DNS settings.
On public wi-fi or over mobile data, fine. In my house, where I have my own filtered DNS? No!
The only solution is to put in firewall rules to block HTTPS to the Google, CloudFlare etc. DNS servers. But that is beyond most home users.
Still surprised that the automatic assumption is that my local (Icelandic, Swiss and German, depending on work) services per definition are worse than some (dodgy) US (law compliant) operator...
News flash: there are some regions in the world that might be higher up the ladder than the US (gasp!) All this probably says more about the person/ organisation making the assumption than about the IRL essentials of the issue...
"Chrome devs have had a little rant about "misinformation", repeating that DNS-over-HTTPS (DoH) won't yet be introduced by default in upcoming builds of the browser."
This response, much like Mozilla's defense of DoH, completely misses the point.
How, or whether, a browser supports DoH is irrelevant. The fact that it exists at all in a standardized form is the problem, because malicious actors (including the adtech world) can use it regardless of browser support -- and there isn't a thing that ordinary users can do about it aside from blocking the execution of JS in the browser. In other applications, you're just hosed unless you're OK with blocking HTTPS access from that app.
The damage has been done, and the only defense against it that I'm aware of is to man-in-the-middle all HTTPS traffic to find and deal with (drop, in my implementation) the DoH requests.
Also, I doubt I'll ever be able to forgive Mozilla for its role in this.
Malicious actors aren't well known for caring much about standards. The problem, if any, is that someone has thought of it - not standardisation, or implementing in Chrome or Firefox.
In fact, now that it has been thought of, implementing it in browsers and providing switches to control it is a very good thing: it reduces the number of bad actors who will roll-their-own and allows control over their use of it. It makes MITM them easier, if that is really what you want to do, and it makes providing your own DoH server under your control easier (if allowed by the controls).
Now it has been thought of, I am glad it has been standardised. My concern is to make sure that software providers provide controls so I can tell all my software to use my DoH server, not Google's, Cloudflare's, my ISP's or anyone else's.
"Malicious actors aren't well known for caring much about standards."
True, but the fact that it's standardized means that it takes less work and resources to leverage it, because malicious actors can just use the mainstream DoH resolvers rather than roll their own. Also, that malicious actors can use mainstream resolvers means that their activities are even harder to detect and prevent.
"browsers and providing switches to control it"
Browsers providing the means to control it is good, but that won't affect malicious actors at all. The browser can only change how the browser itself uses DoH -- it has no control over programs that engage in DoH lookups without using the browser-provided mechanisms.
My objection to DoH is that it abuses port 443, effectively removing its activities from my own ability to control. Thus the need to MITM HTTPS connections -- that's the only way to claw control of my own systems back and regain some of the security that DoH removes from me.
"My objection to DoH is that it abuses port 443, effectively removing its activities from my own ability to control. Thus the need to MITM HTTPS connections -- that's the only way to claw control of my own systems back and regain some of the security that DoH removes from me."
But that's the exact problem. If it uses its own port as DoT does, then the port itself can be hijacked, if not by you, then by anyone upstream. And if the MITM presents itself as the authoritative server complete with keys, there's no way to distinguish between them.
Put it this way. The tool YOU need is the exact same tool BIG BROTHER needs, too.
"The tool YOU need is the exact same tool BIG BROTHER needs, too."
Indeed. But the fact that that's true doesn't eliminate my need -- that's why all the existence of DoH means is that I have to man-in-the-middle all HTTPS traffic on my own networks. I hate having to do that, but there it is.
MITM won't work when we get to the end game.
I already have an Internet of shite device that tries to phone home, no matter what I do. I even tried to MITM it, but it is hard coded to look for a specific certificate on the other end and if it can't connect to that server (port 443), or connects to a MITM certificate, it shuts up shop and won't play anymore.
Now imagine connections to ad servers behaving the same way when built into set top boxes etc, not just browsers. Pi hole won't help and setting up your own dummy service won't work. This is the end game for Google, I am convinced of it. Apart from this, I don't see what problem DOH is meant to fix.
Like anything else, crackers come in various skill levels. To anyone involved with professional, engineering-level actors, DoH is just another application of anything-can-go-over-anything. As I mentioned when this first came out, if I wanted to, I could implement DNS-over-SQL on a standard port.
But the fully-competent actors are never going to be the only threats worth defending against. For a majority of operators, nation-state actors probably don't even hit the list of reasonable concerns. Script kiddies are.
And DoH makes it much, much easier for the script kiddies. And the "adtech" companies.
And then there is the whole issue of Google itself acting very much as a bad actor in a number of ways, and DoH feeds directly into some of that.
"[..] but won't necessarily be automatically used in upcoming builds of the browser"
I'd wager the time frame Chrome devs work with and most of the rest of the world are very far apart. when someone says the above statement I'd have an expectation of that time frame being at least 2+ years, perhaps even 5 years. I'd be quite surprised if within the next 12 months they don't have it on by default(or at least to the same extent firefox has it on anyway). Google and Moz seem to be quite aggressive at pushing this kind of stuff. (Disclosure I bailed on firefox for my main browser at v37 I think it was, on Palemoon since, I do have firefox installed and use it very casually but not my main browser and I don't use Chrome).
For me, as someone who has run DNS for more than 20 years, am still waiting to see non service provider implementations(stuff that I can run myself for my own recursive resolver and is reliable at least) of this DoH -- not that I am in any rush. I checked a few months ago and there wasn't much of anything, checking again now and I don't see anything obviously new in this area.
"am still waiting to see non service provider implementations(stuff that I can run myself for my own recursive resolver and is reliable at least) of this DoH "
If you're interested in running your own DoH resolver, and you're running Linux, then dnscrypt-proxy is the easiest way forward. It can act as a DoH server.
Also, check out the DoH RFC (https://tools.ietf.org/html/rfc8484) -- the DoH protocol itself is not complex and could be easily implemented if you can code (although there are several security gotchas involved). Here's a simple implementation written in PHP: https://github.com/NotMikeDEV/DoH/blob/master/dns.php
thanks for the info that does look interesting and has not turned up on my searches before. However I don't think it does what I'd like to think it does. It seems to just be a proxy to forward DoH requests to another DoH host.
according to https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry
"It responds to standard DNS queries, and can be thus configured in network settings in place of your router's or your ISP's resolver.
But when it receives a query, it will encrypt and authenticate it before sending it to upstream servers able to understand the encrypted protocol."
key point being "upstream servers able to understand the encrypted protocol".
Unless it can handle DoH and hand it off to a local DNS running regular old DNS on port 53 (should be just as secure as the "insecure" traffic is just going to localhost at that point from the proxy.
also looked at https://wiki.archlinux.org/index.php/Dnscrypt-proxy
and it referenced cloudflare as well, no obvious indication it can handle DoH -> regular DNS (which would allow someone to run a local DoH system).
I could be misunderstanding the docs I just spent a couple minutes looking
dnscrypt-proxy is a proxy, but it can respond to DoH requests and proxy them to any other DNS resolver, whether encrypted, using DoH, or standard. I'm not sure if this is the best configuration guide, but here's one: https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/
I wonder what, if any, impact DoH will have on spam filters.
These all depend, to some extent, on black/grey/whitelist providers such as Spamhaus and most of these use DNS queries to interrogate blacklists. In fact the earliest blacklist servers used standard DNS server software and populated their A records with the names and IPs of blacklisted hosts instead of hosts which the DNS is authoritative for.
Since it would appear that obvious DoH implementations, such as ISPs replacing their DNS servers with DNS->DoH translators to handle outgoing DNS queries, would interfere with e-mail blacklisting services I'm a little surprised that this doesn't seem to be mentioned at all amongst the DoH ballyhooing and razzamatazz.
Surely that depends on what application issues DoH requests. I agree that it will have no effect on applications in general if DoH is only used by web browsers. However, that implies that either:
- NO other applications will use DoH unless they are modified to use DoH queries in place of the current plaintext DNS queries
or
- somebody or something, i.e. your ISP, your router, some translation process you installed, intercepts outgoing DNS queries, converts them to DoH queries before passing them on and does the reverse translation to DoH responses.
I'm pointing this out because, if DoH takes off, it is unlikely to to remain a browser-only option and, as its going to need configuration files, security certs, etc, it would seem unlikely that it will get built into every program that currently does DNS lookups, hence my original worry that we'll end up with yet another system process to support the DoH query API and that this will impact applications using DNS queries that those pushing DoH have never thought about.
Last but not least, the DoH API had better operate asynchronously, i.e. must NOT wait for for a response before issuing the next query, oy it will simply be a bigger and better bottleneck on throughput.
What about internal websites? I have various websites - Exchange OWA, NextCloud, etc, that resolve to local addresses on my LAN, and to my reverse proxy from outside. Work has similar for its LAN.
If it gets the external address from inside the LAN, it is not going to work.
I posted a big post here, but cloudflare said my posting was blocked.
EDIT: I give up. It seems cloudflare is sensoring posts mentioning cloudflare :-)
Basically, see subject, or view following link:
Here's my post http://www.welshgit.net/misc/dns_blacklisting_is_not_how_the_IWF_blacklist_operates.html
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
