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.
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.
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
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 192.168.11.2, you run and execute a rule like this:
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.
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.
HTTPS is as different from HTTP as sending a security-sealed envelope is from sending a postcard. So, in a an over-simplified nutshell we’ve prepared this image:
Many mainstream Internet services already offer services over https, but have not discontinued their http services. A good example is YouTube. You can visit YouTube via http OR https. Neither option is forced. This makes sense for YouTube because http in its clear-text, non-secure form provides all sorts of advantages including caching along the way, therefore faster/better viewing by some end users. This is especially valuable in remote areas where good quality bandwidth is not yet a reality.
However, the vast majority of Internet users have sufficient bandwidth to use an HTTPS-only policy. If that’s you, and you want to enjoy some of the additional benefits of an HTTPS-only profile, here’s what you would experience if you landed on youtube.com via HTTP and not HTTPS:
Here are some good reasons you might want to force https in some environments:
Policy enforcement. You may have a written policy that certain computers or staff may never submit any confidential information over insecure means. This would enforce that policy and dramatically reduce the risk that the policy was violated unknowingly or unintentionally.
Thwart any and all identity theft and drive-by malware installation attempts. Malware and identity theft sites have never yet been spotted on SSL-protected sites (except for brief periods where an SSL site may have been compromised). Generally speaking, an SSL-enabled site can be traced back to individuals in a company and you can even “follow the money” in terms of who paid for the SSL certificate.
Prevent sniffers from intercepting your traffic for the purposes of man-in-the-middle attacks, privacy violations, content re-direction, ad-insertions, profiling you, etc, etc. Just imagine what a post-card in-transit facilitates vs a secure envelope.
The biggest benefit to this kind of enforcement is that it bypasses the need for end-user education, and thereby eliminating significant risks.
Over the coming weeks we will release this feature to public users of DNSthingy along with our own results of going about our day with an HTTPS-only enabled profile.