Https is the future and the future is (finally) here. Secure HTTP requests that provide end-to-end encryption between the client making the request and the server providing it with the requested content is finally making some headway, with almost a third of the top one million sites on the internet serving content over SSL:¹

But what this chart doesn’t show is an important subsection of HTTP traffic that is unfortunately infamous for a general lack of security: IoT. The “internet of things,” as it is called, is famous for fiascoes that have allowed hackers to break into the privacy of homes, spying on consumers via internet-enabled nanny cams, gaining access to so-called “smart locks” to break into houses, obtaining sensitive information, and exposing private content and data thanks to insecurely designed consumer products and services that live on the local network.

This segment of “web” traffic has long been plagued by insecure defaults and abysmally poor (in)security practices that can best be summarized as “non-existent” that have lead to countless recalls, security leaks, and more in the past ten years – a trend that will likely only continue at an even more alarming rate as IoT devices become cheaper and more prevalent with today’s gadget-hungry consumers.

There’s so much that’s wrong when it comes to security in the home that we should really be doing whatever we can to encourage better security practices – not, as the major browser vendors have taken to doing, punishing those that attempt to adopt better security. Because that’s the current state of affairs when it comes to providing SSL-encrypted HTTPS for configuration pages, live streaming feeds, etc. served up by IoT resources on the local network.

The problem that we’re talking about is the fact that if a device on your network, identified by its IP address falling in the range of reserved IP addresses per RFC1918 (for example, everyone’s favorite 192.168.1.1 or the corporate-preferred 10.0.0.1), all major browsers will throw up a scary looking warning page telling you that the site you’re trying to visit is not to be trusted, here by monsters, proceed at your own risk, and beware of hackers trying to steal your potatoes.

Here’s what trying to access an HTTPS secured web page on the local internet that responds with a self-signed Certificate with its IP address as the common name looks like in Chrome, Firefox, Internet Explorer, Edge, and Safari:

What do you see? Red. Lots of it. Warning. Blood. Death.²

The scary red warnings aside and the horrible user experience of an interstitial aside, of all the browsers in question, only Firefox doesn’t use scare mongering in the text, and instead of warning you that hackers are trying to steal your unborn children, it merely suggests that perhaps the owner of 192.168.1.1 has configured their website improperly.

The problem is that all these dialogs (yes, even Firefox’s) are just plain wrong. Not just annoying and unnecessary but outright wrong.

As of January 1, 2013, the official orders from the CA/B forum (an organization formed of browser and certificate vendors to promote security on the web) were to no longer issue certificates for RFC1918 IP addresses and other local resources that expire past November 1, 2015 – and to forcefully revoke any non-expired certificates that remained valid past October 2016.

Certificate authority Digicert sums up best the list of resources that are affected:

• Any server name with a non-public domain name suffix. For example, www.contoso.local or server1.contoso.internal.
• NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
• Any IPv4 address in the RFC 1918 range.
• Any IPv6 address in the RFC 4193 range.

Basically, it’s literally not possible to get a security certificate signed by one of the trusted certificate authorities (which is the metric your browser currently uses to determine if it should show a scary warning or let the request through unscathed).

Additionally, one of the biggest benefits of HTTPS is that it protects against the very effective DNS spoofing attack, wherein any attacker can throw up a hotspot that can direct you to a fake page hosted on a server under their control that pretends to be the site you requested – intercepting any data you submit – all the while your address bar still reads http://facebook.com/ or http://nuclearcodes.gov/

But this entire class of attacks doesn’t apply when requesting resources by IP. There’s no DNS involved, and by definition, these addresses are “network specific” – i.e. 192.168.1.1 when you’re on one network is a different 192.168.1.1 than when you’re on another. In other words, the “attack” that your browser is trying to protect you against (one server pretending to be another) is actually how IP addresses in the RFC1918 range were designed to work.

What makes this particularly bad is that these same browsers won’t show you this scary warning if you try to visit such a page over plain, old HTTP:

There’s not much to see – it’s just a normal web page served over HTTP with no scary warnings, no red exclamation marks, no hidden “click here to continue at your own risk” links. Just the page you requested, as it was meant to be shown.

While there are proposals to mark HTTP (aka actually insecure) content as insecure by default in future versions of major browsers (here’s the link to the details for Chrome), this does not extend past including a small (not red) info message in the address bar that only appears when the user is filling out a form on the site in question, like this:

Today there is absolutely zero reason for an IoT (or router) developer or vendor to embrace HTTPS when all it will bring them is an endless stream of complaints from grumpy users (at best) and frantic emails from hyperventilating less-tech-savvy clients that think their smart lightbulb has been hacked by Russian spies, when all they have to do to avoid that situtaion is not use HTTPS and stick to insecure HTTP for the foreseeable future.

In fact, the only way workaround for this for a lan-only device that is not internet accessible but still wants security on the intranet – remember that non-public TLDs like .lan or .local are forbidden from obtaining SSL certificates – is to obtain a certificate for some website https://example.com/ and, after obtaining said certificate, modify its DNS settings so that it points to an internal IP (where a copy of the certificate is installed), a process by means of which the owner of the domain example.com can prove their ownership to the CA and then make the decision to redirect it to an internal resource. But an (unspoken?) rule of the web is that TLDs like .com and .org are for publicly-accessible, internet-facing resources (even if behind a firewall) and not for internal-only resources.

In summary, there’s no compelling reason to keep the security interstitial when visiting HTTPS resources presenting self-signed certificates on intranet IP addresses. If you’re not yet convinced of the importance of the matter, put aside consumer electronics and IoT devices and look at corporate networks instead. A subnet like 10.0.0.0/24 can host 224 devices on the same network. Certainly it is imperative to streamline the process of securing requests internal to such a network, even if they are not accessible from outside the internet and not eligible for a CA-signed certificate from one of the recognized/whitelisted certificate authorities?

It’s ironic that – from the very start – in the pursuit of “security” browser vendors (all of them) have consistently treated HTTPS resources presenting self-signed SSL certificates as inferior to plaintext, and here we are some 20 years after the initial release of Internet Explorer 5.0b1 in June of 1998 still punishing those that try to secure their content as best as they are able.

While the discussion of how to treat self-signed HTTPS requests over the web has been hashed to death over the years, the question of how to present such requests when the server in question is identified by a private IP on the intranet is hopefully a lot more clear-cut and more of an oversight than a purposeful decision. The fact that most recent/soon-to-be-released versions of major browsers will not present a security warning for the local loopback address 127.0.0.1 aka localhost when served over HTTPS with a self-signed certificate gives us some hope that perhaps CA/B or at least just browser vendors will realize the importance of making HTTPS accessible for everyone – IoT and intranet devices included – and hopefully no longer punish those that do literally all they are permitted to secure the servers under their control.

1. Source: BuiltWith SSL trends ↩

2. OK, maybe I’m exaggerating.. a little. ↩