On the 2nd of July 2019, Mozilla was named as one of the finalists in ISPA’s internet villain of the year “for their proposed approach to introduce DNS-over-HTTPS”. The reason for this was that the Internet Services Providers’ Association (ISPA) suggested that Mozilla’s introduction of DNS over HTTPS would bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK. Mozilla’s response? They were “surprised and disappointed that an industry association for ISPs decided to misrepresent an improvement to decades old internet infrastructure”. So what is DNS over HTTPS? And does its promotion by Mozilla justify internet villain status?
Let’s get technical. HTTPS stands for Hypertext Transfer Protocol Secure, and it improves on HTTP by encrypting the traffic between clients and servers, which is important for three main reasons. First, it offers privacy, preventing eavesdroppers from reading the content of the traffic (including passwords!). Second, it ensures integrity, which it achieves by preventing malicious actors from changing the content of the traffic. This means you can be certain that the message you receive is the same as the original message that was sent. Finally, HTTPS allows for identification. Messages are sent with digital signatures which identify the sender, meaning that when you visit a website you can be sure that the page you are seeing is the one you think it is (rather than a nasty counterfeit).
The process of negotiation between client and server which enables this nifty encryption is called the handshake, and consists of five steps. The handshake begins with the client hello, which involves the client sending a list of encryption options (cypher suite) to the server. This is followed by the server hello, in which the server chooses one of the encryption options and responds to the client with their certificate including their public key.1 This public key is then used by the client for step three: client key exchange. After verifying the server’s certificate, the client generates a pre-master key, encrypts it with the public key it received alongside the certificate, and sends it to the server. This pre-master key is then used in step four, change cypher spec, so that both the server and client can separately create matching symmetric keys. Finally, the server and client exchange test messages encrypted with their new symmetric keys to make sure that everything is in ship shape. Once they’ve confirmed that the newly established encryption method is readable by both parties, they continue to encrypt all their data transmission with those symmetric keys for the rest of the session.
This brings us to DNS, and the rationale for encrypting it with HTTPS. DNS stands for Domain Name System, and operates like a phonebook for the internet. The web server that actually serves you the web page you’re visiting is identified by IP address (e.g. 188.8.131.52) which is very specific but hard to remember, like a phone number. Fortunately, DNS servers exist so that you can look up websites by their memorable names (e.g. duckduckgo.com), like you would look up a person’s name in a phonebook to find their number. If you’re visiting a website you’ve visited before, then there will likely be some record of its IP address stored locally on your computer, and that’s where your computer looks first when you hit enter in the address bar.2 If the relevant ‘phonebook entry’ can’t be found locally on your computer, a request is made to a DNS server somewhere on the internet. This is where the security concerns arise. Traditionally, HTTPS encryption has only begun once you’ve found the website you’re looking for and its server has successfully shaken hands with your browser. This means that your web browser’s DNS queries (which were sent while you were still looking for IP address of the website) have been sent in plaintext (without encryption!), visible to any DNS servers that are contacted (likely including your internet service provider’s) in addition to any routers on the path to those servers. Although the potential negatives of this aren’t as severe as your bank details being intercepted during an unsecured online shopping spree, a comprehensive record of all these unencrypted DNS queries could be built and sold to advertisers. Furthermore, unsecured DNS is vulnerable to DNS hijacking, wherein attackers sneakily redirect you to scam websites without your knowledge. DNS over HTTPS (DoH) avoids these problems by securing the connection between the client and the DNS server before the ‘phonebook’ lookup is performed.
Mozilla have begun to roll out DoH as the default DNS lookup method in Firefox to users in the US, but have confirmed that this will not be the case for their users in the UK. This decision was likely made in response to complaints made by groups described in an article in The Register as “an unholy alliance between a UK ISPs’ lobbying association, social conservatives across Parliament and the civil service, the Internet Watch Foundation and selected small-c conservative national newspapers [who] combined to screech blue murder earlier this year at Mozilla”. The aforementioned Internet Watch Foundation argue, as quoted in a separate article in The Register, that “DNS over HTTPS […] could expose millions of people across the world to the worst imagery of children being sexually abused and could mean that the victims of such abuse could be exposed to countless sets of eyes”. On the other hand, Matthew Prince (CEO of Cloudflare, one of the companies offering DoH) is quoted later in the same article, questioning whether “it [is] more important to keep people’s information private and not allow ISPs to sell that data or repressive regimes to block internet access”. He reckoned that “if you believe those are important goals then, one way or another, you have to encrypt DNS”. In short, like many debates around encryption in mass-market technology, it boils down to a toss-up between individual privacy and effective policing.
Public keys are one half of a cryptographic system called asymmetric cryptography wherein public keys are shared publicly (hence the name) and can then be used to encrypt messages in such a way that they can only be decrypted by the secret private key alongside which the public key was made. This is an improvement on symmetric cryptography because if you encrypt all your messages with a shared private key, you need to be really careful about how you share that key in the first place. ↩