Privacy-Protecting Portable Router: Adding DNS-Over-TLS support to OpenWRT (LEDE) with Unbound

by Junade Ali

If you want to skip ahead to instructions, scroll to the next section. But I, like a TLS handshake, am very verbose so please enjoy this opener.

Imagine this scenario — I’m at a restaurant and need to have a private phone conversation but unfortunately my phone’s battery is drained. To get around this problem, I borrow my friend’s phone and dial the number — to protect my privacy I walk outside. When I’m done with the call, I come back inside and return the phone.

Whilst the phone itself doesn’t store the conversation I’ve had, it does have a log of the recently dialed number, if the friend from whom I borrowed the phone wanted to, they could easily see who I actually called — even if they don’t specifically know the topic of conversation.

Sometimes, the data about who you’ve spoken to can tell an aweful lot about the conversation — if someone was to call an emotional support hotline or a debt collector, you could probably infer a lot about the conversation from the caller ID.

When we browse the internet, we use encryption to try and protect the conversations we have. When you connect to a website over HTTPS, a green padlock lights up on your browser and let’s you know that your conversation is encrypted such that it is computationally difficult for an adversary sitting between you and the website’s server to see what you’re talking about.

I’ve previously blogged about how, under certain circumstances, it is possible to strip away this this encryption and the mitigations that websites can use to prevent this. Unfortunately, there is a far more fundamental problem to privacy online.

As is common IT knowledge, before your browser makes a HTTP connection to a website (say, cloudflare.com), your client needs to make a DNS query to work out the IP Address where the HTTP connection should be made. The same is true for any other application layer protocol, when you connect using a hostname instead of an IP Address. For a primer on DNS, we have an article on the basics of DNS on our Learning Centre.

Whilst encryption technologies have been fairly long-standing for HTTP itself, only recently have such encryption techniques been standardised for DNS. Chances are, if you don’t know if your DNS traffic is encrypted — it isn’t.

In practice this means that when you connect to a website that uses HTTPS, even though your conversation is encrypted — someone able to intercept your connection is able to see what website you’re looking for and (depending on how the site is secured) even manipulate the response to get you to communicate with a different server.

This is particularly useful for evesdroppers; be they the network that’s running the free Wi-Fi hotspot looking to sell your data to targetted advertisers or the hacker sipping on a latte whilst intercepting your network traffic (ironically dressed in a black hoodie and a balaclava).

By switching your DNS resolver to use Cloudflare’s DNS Resolver, you get a faster browsing experience whilst ensuring that the people who run your DNS resolver aren’t selling off that data to target you with ads. However, whilst Cloudflare Resolver supports both DNS-over-HTTPS and DNS-over-TLS, to make sure the connection between Cloudflare Resolver and you is encrypted, you may need to follow some additional configuration steps like enabling a DNS over HTTPS client.

This blog post explains how you can configure an OpenWRT router to encrypt outbound traffic to Cloudflare Resolver. This is particularly useful when you want to protect the traffic for the devices in house which may not support encrypted DNS protocols; such as your TV or IoT enabled toaster. Whilst local clients may still explicitly override your local DNS resolver on your router, many will default to using it.

OpenWRT (LEDE)

Over the weekend, prior to writing this post, I ordered a new wireless router, the GL.iNet GL-AR750. This router has a very small form-factor and is marketed as a “Travel Router” and can act as a Wi-Fi repeater as well as a traditional Wi-Fi Router. At it’s longest edge, the router itself is around the length of my index finger:

I didn’t just order this specific router because of it’s form-factor, it also comes pre-installed with OpenWRT — an embedded Linux-based operating system that’s well suited for routers. In May 2016, OpenWRT was forked as LEDE (the Linux Embedded Development Environment) and was re-merged with the OpenWRT project in January 2018.

For those of you without a router with LEDE pre-installed, you can follow along with this blog post on any other router that supports being flashed with the OpenWRT firmware; more information can be found on the OpenWRT Support Devices page. Though, please be aware that, depending on your device, this may carry some risk.

Support for DNS-over-TLS (or, the lack of)

The router I’m playing with has a configuration option to configure upstream DNS Resolver that it will use when a query isn’t cached in it’s own internal resolver. This local resolver is then suggested to clients that connect to the router.

For the sake of experimentation — through the web UI, I am able to configure this router to use 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 and
2606:4700:4700::1001 as the upsteam DNS servers (with the IPv6 addresses updated if the network doesn't support them):

By connecting the router’s WAN port to my computer, I am able to sniff traffic as it leaves the router by using Wireshark before it goes out to the actual WAN. When a DNS query isn’t in my routers cache it is forwarded to 1.1.1.1. As my router is sending these queries unecrypted instead of using DNS-over-TLS, I am able to see these DNS queries being sent around the internet in unencrypted form:

Although Cloudflare Resolver supports DNS-over-TLS, unfortuantely my router doesn’t and will simply send all queries unencrypted.

Setting Up DNS-Over-TLS

By default, LEDE comes pre-installed using Dnsmasq as an internal resolver and therefore doesn’t support DNS-over-TLS. So that we can get our requests encrypted, we’re going to replace Dnsmasq with Unbound and odhcpd. I’ve based the steps I’m following from the very useful OpenWRT Unbound package documentation.

Before we can get started, we need to SSH into our router, if you’re prompted for a password, this will likely be identical to the one you set up for the web portal:

LEDE uses opkg as it's package manager of choice. Firstly, let's update the package list, then we install Unbound with Unbound-Control and the full version of odhcpd:

opkg update 
opkg install unbound odhcpd unbound-control 
opkg remove dnsmasq

Note that you can additionally install the Luci app for Unbound should you wish to control it with the standard user interface.

opkg install luci-app-unbound

As my router isn’t currently running vanilla LEDE, it’s user interface won’t be altered if I was to install this and I haven’t tested this module myself.

With Unbound in place, we can add some configuration to ensure Unbound uses 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 and
2606:4700:4700::1001 as the DNS resolvers with TLS encryption. I've done this by appending some configuration to /etc/unbound/unbound_ext.conf using Vim:

forward-zone: 
  name: "." 
  forward-addr: 1.1.1.1@853 
  forward-addr: 1.0.0.1@853 
  forward-addr: 2606:4700:4700::1111@853 
  forward-addr: 2606:4700:4700::1001@853 
  forward-ssl-upstream: yes

In the Unbound configuration file at /etc/config/unbound, I've added some required configuration parameters as outlined in the package documentation. In my case, I backed up the configuration file and simply used the following:

config unbound 
  option add_local_fqdn '1' 
  option add_wan_fqdn '1' 
  option dhcp_link 'odhcpd' 
  option dhcp4_slaac6 '1' 
  option domain 'lan' 
  option domain_type 'static' 
  option listen_port '53' 
  option rebind_protection '1' 
  option unbound_control '1'

If you do have additional parameters in the file, ensure that nothing overrides the parameters set — being especially cautious about the unbound_control parameter.

I’ve also merged the following configuration with /etc/config/dhcp (leaving some existing entries alone):

config dhcp 'lan' 
        option dhcpv4 'server' 
        option dhcpv6 'server' 
        option interface 'lan' 
        option leasetime '12h' 
        option ra 'server' 
        option ra_management '1' 
config odhcpd 'odhcpd' 
        option maindhcp '1' 
        option leasefile '/var/lib/odhcpd/dhcp.leases' 
        option leasetrigger '/usr/lib/unbound/odhcpd.sh' 
...

Finally, we can enable autostart on Unbound and start it:

service unbound enable 
service unbound start

Here’s the proof of the pudding; when we intercept DNS queries between our router and the wider internet, we’ll notice they are encrypted with TLS v1.2:

Conclusion

In this blog post, we’ve discussed how encrypting your DNS traffic can help privacy protect your internet browsing. By replacing Dnsmasq with Unbound, we are able to allow OpenWRT to take advantage of DNS-over-TLS to help encrypt our web traffic.

Originally published at blog.cloudflare.com on April 9, 2018.