Block, Subvert, Inspect

Some of the recent discussion on the DNSops list have prompted me to wonder if DNS-over-HTTPS actually solves any significant problem or if in fact it may be a case of the “cure” being worse than the disease.

As you may have gathered from my previous articles I’m not a great fan of DoH, and am concerned about the harm it causes to the security controls in place around DNS. As such I’ve been considering how to deal with that problem and to limit the damage caused by DoH, I don’t expect to be able to stop all of it but that’s true of most unwanted activity. So how to handle it, the choices seem to be block, subvert or inspect.

Blocking is the easy approach and one that ( the much cited ) oppressive states will be able to do as easily as home users, which rather ruins one of the claimed benefits of DoH in the first place. In the normal run of events DoH configurations have to first look up the address of the DoH server which they do via normal DNS. These server address will, by and large, be well known. This means that as with other unwanted sites you can just block them at the DNS level. If the client can’t resolve the DoH server then it can’t query it, and will fall back to normal DNS or simply not work. Of course to avoid this you could use an IP address instead in which case the IP address is going to be more static and can therefore be blocked at the firewall level. For users to be able to use DoH the addresses of the server have to be advertised and at that point the information is easily put into block lists for use by state controlled firewalls, home routers or corporate/ISP/hotspot firewalls. This probably won’t capture every single DoH server but then again you’re unlikely to ever catch all tunnelled traffic.

When you consider that initial boot strapping look up required by DoH, the opportunity to be a little bit sneakier presents itself. If you happen to be in an environment where you can mandate trusting your own certificate authority, then there’s no reason why you can’t impersonate the trusted DoH server. All you need to do is insert your own DNS response ( easily done via a RPZ ) and cause the DoH server address to resolve to the IP address of your choosing. On that address you run your own DoH server using a suitable certificate as issued by your pet CA. To the end user DoH is working properly, meanwhile you have the same or better visibility than you did before. Obviously this option isn’t available to home users, hotspot operators and the like but entirely viable for large enterprises and state actors.

The last option is to inspect. If DoH traffic is indistinguishable from normal HTTPS traffic then you’re forced to do deep packet inspection of all HTTPS traffic. This is obviously costly and requires a lot of effort, again not ideal for the home user or hotspot operator. Plausible though for our putative oppressive regime or large ISP. It doesn’t need to block or detect it all – just most of it. Apart from the major DoH providers being well known and so more easily identified, my suspicion would be that in time firewall vendors will be able to make a fair amount of head way in detecting the traffic patterns associated with DoH traffic. DoH traffic should be quite distinctive in terms of request and response size at least so that you can reduce the amount of traffic you need to take a closer look at, especially in combination with the destination address. Granted this will be trickier if the DoH server is on the same platform as another common HTTPS destination and padding and other techniques would also help counter that but at that stage DoH has properly become malicious traffic.

In some ways I accept I’m arguing that the impact of DoH won’t be as bad as I’ve previously claimed. However the increased overhead on support is still substantial, as is the loss of control for end/home users who may well be using a DNS based product to control what family members access or to protect themselves from malicious sites and adverts ( e.g. PiHole users ). I think we can be fairly sure that Google won’t be blocking their own ad servers any time soon for instance. The idea that this will in anyway assist people in oppressive regimes ( one of the big claims made by the DoH advocates ) seems to me to be fairly nonsensical and may result in people having a false sense of protection. Worse than that though as was observed on the DNSops list many countries require ISPs to block access to various sites for legal reasons. Now you may think that this is a bad thing and should be worked around, and I may even agree with you, however the law in those countries says that ISPs must do this so do it they must. Currently, if the UK is anything to go by, ISPs can meet this obligation by saying “we’re blocking the server name”, a cheap, lightweight and easily circumvented measure but enough to keep the state happy. If DoH gains enough traction and becomes widely prevalent then the state will insist that the ISPs take further action. So they’ll either have to subvert the DoH servers ( and that opens a huge can of worms ) or more likely ( at least if the Government has a say ) they’ll have to go the inspection route. So as a result of an initiative to solve a comparatively small “problem” we’d end up with our ISPs having to monitor even more of our activity and in greater detail. Of course the alternative is that the relevant Governments would be quite happy to insist that the DoH providers also have to block and snoop as they require. As I said potentially very small gains that can already be solved by other means for a far greater cost.

As a final thought I do wonder if there might not be an interesting liability case down the line, as Mozilla’s argument is that users don’t know how to set their DNS so Mozilla (app developers) need to set it for them. Surely that means they’re taking some responsibility for the choice they’ve taken on behalf of that user. What happens though when taking that decision on behalf of someone removes or circumvents the defences they’d knowingly put in place and results in harm happening that would have been prevented? I am of course sure that the click-license will claim to absolve them of all legal responsibility, but as their argument for taking action is that users don’t know what they’re doing then surely the users can’t also give informed consent to the contract?

Bookmark the permalink.

Leave a Reply