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

    107.178.208.232

    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 192.168.11.2, you run and execute a rule like this:

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

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.

HTTPS-only option

Posted June 13, 2014 by David Redekop to Security

In support of the Reset The Net campaign (by the good folks at fightforthefuture.org, we built a new feature we boringly call HTTPS-only.

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:

https-vs-http

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:

httpsonly

JavaScript will attempt to redirect you from http://www.youtube.com to https://www.youtube.com (if YouTube offers it, which it does, in this case). Otherwise your browser will stay on that window.

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.

More to come…