Encrypted SNI, announced by Cloudflare this past week, is a positive move towards privacy and security. It makes sure that along the path from your browser, all the way to the host you’re contacting, even the hostname such as dnsthingy.com isn’t visible.
However, the side effect of this natural progression of encryption, is that gateways which depend on SNI for Internet Filtering cannot do so any longer when Encrypted SNI is deployed. Transparent filtering, as it is called, is in use by Squid and many other SSL filtering gateways.
On the other hand, the good news is that DNS-based filtering remains as powerful as ever. In fact, DNS-based filtering has a significant advantage over proxy-based technology for these reasons:
Lower RAM and storage resources required on gateway such as pfSense (only a DNS query response vs packet inspection, caching of page contents, etc)
Faster end-user experience (for the time it takes for a DNS query the end-user knows if destination is blocked or allowed)
Better compatibility – no more worries about end-user applications’ proxy incompatibilities
Better IoT security control and connectivity
It is clear that DNS-based filtering is here to stay. Watch for news on how DNS over TLS and DNS over HTTPS have a future on-premise to provide the best of security and privacy, while also facilitating system administrators’ responsibility to provide security at the gateway.
The green circle is what you’re looking for on your local DNS server on your LAN. Then, and only then, according to GRC DNS benchmark freeware, do you pass the test of private IPs being stripped from public DNS queries. As of DNSthingy build 1916 and above, this behaviour is now the default.
This is important because it’s a security strategy to mitigate DNS rebinding attacks that are making the rounds to get into private IPv4 networks which are often presumed to be protected from the public internet.
Steve Gibson on Security Now Episode #673 (show notes PDF) had great coverage on the DNS rebinding attack, after already having covered it in episode #260.
A setting is available in pfSense that is used to enable this setting in the pfSense UI (2.3+) under System -> Advanced:
As long as that box is unchecked as shown in the screenshot, it will trigger build 1916 and onwards to block RFC1918 private addresses (10.0.0.0/24, 172.16/12, 192.168/16) + 169.254/16 subnets as well as IPv6 link-local and the applicable area of NAT64 space. Note that this is also the behaviour with pfSense default DNS resolver (unbound).
On other platforms (ClearOS, ASUS) this behaviour is default as well, starting with Build 1916 and onwards.
To check your build, log into your dashboard -> Router -> rest your mouse over your “Running” version to display your build number as shown here.
The qualifying build is available on pfSense Rapid Release Channel as of 27 July 2018 and will be deployed automatically on other platforms. Keep enjoying your peace of mind!
Traditionally, it has been difficult to block unwanted traffic that is initiated behind an Internet gateway. This is completely understandable considering that a traditional consumer, prosumer, and SMB gateways take an allow all, block some approach. This means that workarounds just need to find one protocol, destination or port that isn’t blocked, and bingo! Your egress channel is now unrestricted using that open hole.
What we are demonstrating here, though, is the opposite. A zero trust model works like this: block all, allow some. This idea of whitelisting is far from new. However, a practical and convenient way to do so has been the challenge. We would like to share with you how we implement a practical solution:
The DTTS (Don’t Talk To Strangers) is currently available for an early adopter group. If you’re interested, kindly contact us via support.
Securing the world of Internet communications with self-signed SSL certificates has had an unintended consequence:
We would like to undo this. The reasons why prosumer-grade or even commercial-grade routers have never done this is two-fold:
The nature of manual firmware upgrade cycles. Manufacturers have traditionally waited for the end-user to download and apply firmware upgrades.
Certificates have an actual expiry date. Therefore, if the end-user does not upgrade the certificate (i.e. firmware), the certificate expires, in which case it’s even worse than a self-signed or unsigned certificate as some browsers don’t even allow for an override to continue.
Since DNSthingy firmware in prosumer gateways are upgraded without the option of opting out, it opened the door for us to include a real SSL certificate and at the very least contribute to the undoing of the comfort level of self-signed or unsigned certificates. When you access the gateway of any of our ASUS routers flashed with DNSthingy firmware and inspect the SSL certificate, this is what you will see:
We recognize that this approach could be analyzed as a weakness insomuch as reverse engineers could capture the private key off any of our firmware devices. That means in combination with DNS poisoning in a man-in-the-middle scenario + possession of the private key, our domain mybox.management could be abused. However, the domain mybox.management is used nowhere else except on the devices themselves, and is irrelevant to our device-to-controller communications. From our perspective, the upside is dramatically more pronounced than the down-side.
When we first began adding DNSthingy functionality to existing high-performance routers, OpenWRT was an obvious win. Over time, however, as we built our functionality to be more platform-neutral and started beta-testing pfSense, IPfire, ClearOS, our engineering team noticed that from a total throughput perspective, AsusWRT is clearly optimized (great job, ASUS!), so we have a good number of our early adopters now running on AsusWRT+DNSthingy (vs OpenWRT+DNSthingy) firmware.
To help with the comparison, refer to this table below and it will become obvious why we are leaning towards AsusWRT going forward.
Captive Portal Setup Wizard
Tops out at ~70mbps
Tops out at ~150Mbps
Yes on all models including RT-N16
Yes on RT-AC68U and above
Read-only (better for security)
A few notes worth mentioning:
Our production firmware upgrades automatically and checks once per 24-hour period.
There is no automatic way of migrating from OpenWRT to AsusWRT (or vice-versa). It requires a manual set of steps including erasing the NVRAM where configuration information is stored. NVRAM configuration is different between the two platforms. If you’re interested, email support and we will be happy to provide you with instructions and support.
At last week’s Google I/O, a session was dedicated to making a case for having HTTPS Everywhere:
Description from the YouTube video:
Data delivered over an unencrypted channel is insecure, untrustworthy, and trivially intercepted. We must protect the security, privacy, and integrity of our users data. In this session we will take a hands-on tour of how to make your websites secure by default: the required technology, configuration and performance best practices, how to migrate your sites to HTTPS and make them user and search friendly, and more. Your users will thank you.