Encrypted SNI death blow to transparent filtering

Posted October 3, 2018 by David Redekop to DNS Security

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.

DNS rebind protection

Posted July 26, 2018 by David Redekop to DNS Security

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!

Blocking third party ads – a security feature

Posted January 23, 2018 by David Redekop to Security

In hindsight, we have verifiable information that blocking of third party ad networks is a necessary security precaution:

These ads and misleading displays are blocked with our default Rule Set which blocks third party ad networks including ones mentioned by Arstechnica.

Keep safe!

How a scam should fail

Posted August 25, 2017 by David Redekop to Case Study Security Whitelist

I’m dumbfounded at how often I personally receive deceptive SMS messages like this one here I just received:

When I opened the message, I see that it would be a motivating message for someone to click on if there’s hope to receive some “refund”, even if it’s someone else’s:

Fortunately I was confident with our zero trust model that I could go ahead and click on the link and was unable to go any further:

This is really what it looks like when you protect an end-user, even if that’s yourself 🙂

Using a Zero Trust Model to block outbound VPN, Proxy, TOR, and P2P

Posted July 28, 2017 by David Redekop to Feature Security Whitelist

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.

Real SSL certificate on our firmware

Posted December 7, 2015 by David Redekop to Feature Security

Securing the world of Internet communications with self-signed SSL certificates has had an unintended consequence:

invalid certificate

We would like to undo this. The reasons why prosumer-grade or even commercial-grade routers have never done this is two-fold:

  1. The nature of manual firmware upgrade cycles. Manufacturers have traditionally waited for the end-user to download and apply firmware upgrades.
  2. 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:

mybox.management certificate

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.

In related news, we salute the efforts of letsencrypt.org‘s sponsors to make SSL everywhere more accessible and affordable. Beta is now open to the public.

OpenWRT vs AsusWRT

Posted May 25, 2015 by David Redekop to Feature Security

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.

Firmware Mode: OpenWRT AsusWRT
Firmware size ~8MB ~21MB
Captive Portal Setup Wizard No Yes
RT-N16 throughput Tops out at ~70mbps Tops out at ~150Mbps
PPTP Server No Yes on all models including RT-N16
OpenVPN Server No Yes on RT-AC68U and above
Auto-upgrades Yes Yes
Filesystem Read/write Read-only (better for security)

A few notes worth mentioning:

  1. Our production firmware upgrades automatically and checks once per 24-hour period.

  2. The firmware upgrade check happens by default at 3am in your local timezone. The local timezone is automatically assigned using javascript timezone detection on the dashboard. You can change your preferred firmware upgrade time-of-day on your dashboard under the Advanced section.

  3. 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.

HTTPS Everywhere

Posted July 1, 2014 by David Redekop to Security

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.

Alexa top 50 https results

Posted June 26, 2014 by David Redekop to Security

We tested the Alexa Global Top 50 sites for https-only functionality and our results are captured in this Google Sheet available to the public:

https://docs.google.com/spreadsheets/d/1HirCBS8bK89-jPrLc2cmru48R-3s9mUTJVwni3DO_Sw/pubhtml

Some interesting takeaways:

  • 29 out of 50 (58%) worked perfectly over https
  • Google (internationally) consistently offers SSL everywhere, and in some countries like US and Canada, even defaults to SSL on its own
  • It appears that every Alexa-ranked company from China offers NO SSL, which facilitates gov censorship
  • Amazon, Yandex, Instagram, Ebay, Craigslist all force http (as does OpenDNS non-dashboard use), likely due to mixed content

Steve Gibson weighs in on HTTPS-only

Posted June 24, 2014 by David Redekop to Security

On today’s Security Now Podcast Episode #461 (at 1:20:55) Steve Gibson was kind enough to read my question/feedback item and weighed in…:

Thanks, Steve, and we agree. It’s only a matter of time before nearly everything will be on https. We will report shortly on our results of top web sites and their https-only test results.