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: 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 could be abused. However, the domain 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‘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:

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.

How to roll your own HTTPS-only service

Posted June 22, 2014 by David Redekop to Security

We want to see the world more secure and more private, so we are sharing with you some details on how we achieved it. This is how you can roll your own, especially if you already have an iptables-based firewall/router.

There are two components and some requirements to achieve this.

  1. Public landing page that re-directs http pages to https automatically.

    If you don’t want to setup your own, you’re welcome to use ours at

    Our server at this IP address contains some code that attempts an SSL/TLS handshake on the incoming http host header, and automatically re-directs you within six seconds if it is successful. We have a published Privacy Policy so you can rest assured that we’re not logging this usage, except to scale it as necessary.

  2. Router configuration that captures/hijacks HTTP port 80 traffic and redirects it to the public landing page above. In our case, our firmware is based on OpenWRT which uses iptables as part of its core operating system. Any other iptables-based firewall (DD-WRT, pfSense or full-scale linux-based gateways) can likely use the same or similar iptables rule. Let’s say that the device you want to protect with an HTTPS-only profile has, you run and execute a rule like this:

    iptables -t nat -A prerouting_lan_rule -i br-lan -p tcp -s --dport 80 -j DNAT --to

A few other considerations you want to make when doing this:

  • Your interface may not be br-lan, it could be eth1 or something else.
  • Any time you have a device-specific rule you want to make sure it becomes a DHCP reservation or assign the IP to the device statically.
  • For any purists out there, this is not a protocol-level checker, but rather a port 80 check only. If a web server runs at an alternate port (other than 80), this approach will not filter any port other than port 80.

It goes without saying that these additional considerations is what DNSthingy takes care of for you automatically. If a device changes its IP address from one day to another, the iptables rule is adjusted automatically. Likewise, if you turn this feature ON or OFF, the rule is added or deleted automatically.

Hopefully you’ve found this helpful. If I’ve missed anything, feel free to leave a comment.

How HTTPS-only option works

Posted June 19, 2014 by David Redekop to Security

In this video we show you how the HTTPS-only works which is now available to everyone with a firmware version of 1.0.7 or later. As of June 19, the firmware has been made available to a few of our subscribers with more to roll out automatically within the next 24-48 hours.