OpenWrt and self-signed certificates

The move to secure most or all of web traffic using HTTPS is generally a good thing; lots of personal information is exchanged via web browsers, after all. Using HTTPS requires web sites to have TLS certificates, however, which has sometimes been an impediment, though Let's Encrypt has generally solved that problem for many. But there are systems out there that may need the HTTPS protection before their owners even have a chance to procure a certificate, IoT devices and home routers, for example. An October discussion among OpenWrt developers explored this problem a bit.

OpenWrt is a distribution that targets wireless routers for the home and it provides a configuration interface, called LuCI, as a web application running on the device. Users can connect to the device over unencrypted HTTP, but that may be problematic in certain environments. By default, LuCI does not listen on the internet-facing side of the router, but is available via both wired and wireless access on the local network, though the wireless network is not enabled by default for OpenWrt. Since the router's authentication credentials could potentially be intercepted by malicious actors, many will want to only enable LuCI over HTTPS.

The project has suggestions for securing access to LuCI, including enabling HTTPS-only access. But LuCI comes with a self-signed TLS certificate, so users will have to click through a browser security warning every time they access LuCI, which is not a great user experience. There are instructions for creating a new self-signed certificate and installing it on the device and on the client side so that the warnings are silenced. That mechanism has a number of downsides, not least that the new certificate needs to be installed on every system that will be used to access LuCI.

In theory, getting a certificate from Let's Encrypt would solve many of the problems, but that solution is not without hurdles either. For one thing, Lets Encrypt uses the Automated Certificate Management Environment (ACME) protocol, which requires that the system requesting the certificate be connected to the internet. Beyond that, a device will need a domain name that can be used by the issuing server to connect to them; obviously, "luci.openwrt" and similar sorts of names that are currently being used will not work for that purpose.

On the openwrt-devel mailing list, "abnoeh" proposed a somewhat complicated scheme that would provide a means for OpenWrt router devices to get working certificates. A "technically constrained subordinate CA" would be created that could sign certificates for sub-domains of "luci.openwrt.org", though it is not entirely clear which existing CA would be willing to sign subordinate CA keys—Let's Encrypt and DigiCert are mentioned as possibilities. The proposal calls the new CA the "OpenWrt CA".

A router that needs a certificate contacts the OpenWrt CA over an encrypted channel and sends its SSH host key; the CA hashes the key and reserves the "SSH-hash.luci.openwrt.org" host name for the device. The OpenWrt CA sends back a nonce to the router, which creates a certificate signing request (CSR), hashes it, and then signs the hash, nonce, and a timestamp using its SSH host key. The CSR and signed message are sent back to the OpenWrt CA, which verifies the information and signature, signs the certificate, and sends it back to the device. At that point, the router has a valid certificate; it can intercept connections to SSH-hash.luci.openwrt.org, route them to itself, and LuCI over HTTPS can be used without browser warnings, though the host name is perhaps not the friendliest.

There are still some problems to be solved, of course and routers that are not already connected to the internet will be unable to participate. In addition, abnoeh noted that the project would need to run the OpenWrt CA server and figure out a way to reasonably rate-limit requests from clients. There is also a question of what the openwrt.org DNS servers should return when SSH-hash.luci.openwrt.org requests are made.

Michael Richardson wondered if the project could find a CA that would be willing to set up the subordinate CA and whether the CA/Browser Forum (CABForum) rules will allow what is needed. If the subordinate CA violates those rules, the browser makers would remove the parent CA from the browsers unless it revoked the subordinate, which would be a horrendous mess. But abnoeh thinks those rules do not prevent the usage suggested.

Abnoeh did ask if it made sense to dispense with HTTPS entirely, though, and to wrap LuCI with SSH instead. Alberto Bursi suggested considering mobile apps on Android and iOS as a way of sidestepping the HTTPS certificate problems, but Sam Kuper cautioned that an app wouldn't necessarily solve the problems, even though it seems like an attractive approach. There are some users who lack a device to run the app, for one thing, but the app will also have to deal with certificate issues in one form or another. "Ultimate[ly], SSL/TLS on IoT is a hard problem: the two technologies are currently not *fully* mutually compatible without imposing some burden on the user."

Some were not sure of the need for CA-issued certificates, however, at least by default. Fernando Frediani said that most OpenWrt users would not find it strange to have to click through the certificate warning and, for the most part, LuCI is only accessed from trusted networks. But Richardson cautioned that those assumptions may lead to unexpected kinds of problems:

Bursi said that OpenWrt users already have to jump through a fair number of hoops to even get it running on their devices, so it is probably a mistake to think that they will not change the root password; by default, OpenWrt does not enable WiFi, for example, which is probably not what these users are looking for:

Many in the thread thought that abnoeh's idea was worth pursuing to make it easier for users who do want a real certificate, but Bas Mevissen suggested that the proposal might be "making things more difficult than they need to be". Owners should be doing the initial install on a trusted LAN and configuring the device before connecting it to the internet or allowing others to use it.

The main concern that Mevissen had was about how to transfer credentials to a new install. "Even though the user/admin should be alone on the connection, sending those unencrypted over the line is not desirable." Abnoeh suggested using a USB drive to transfer those kinds of credentials, at least for systems that have a USB port.

Richardson wondered about less technically savvy users, though. Mevissen said that OpenWrt should simply "aim to get the best possible security with the least effort (on user side) possible". Mevissen noted that other routers typically come with self-signed certificates for their administrative interfaces, so OpenWrt would not be out of step to do so; providing users with ways to replace that certificate is important, but the complexity of abnoeh's proposal does not seem needed.

OpenWrt is far from alone in having this problem; as noted, IoT devices have it as well. Other web-based administrative interfaces (e.g. Webmin, Cockpit) have similar certificate-bootstrap problems, though they may generally target folks who are more technical than your average home user. For good or ill, secure web access was tied to the CA system from the outset—with the self-signed option as an escape hatch. The CA model does not work for all use cases, by any means, and the escape hatch is slowly closing, however. It is not entirely clear what systems that want to provide secure HTTP access in restricted environments of various sorts (e.g. no domain name, no internet connection) can do—at least without compromising the existing HTTPS security story for other users, especially those of a less-technical bent.