OpenWrt and Self-Signed Certificates
lwn.net
lwn.net
In the end, I used WebRTC from an external HTTPS webpage I'm hosting and a "mailbox" service where two peers can post and retrieve messages from a UUID. To communicate this UUID on the local network to the peer, I first used an <img> tag with the UUID in the URL query string but this method was recently broken because of increased security measures by browsers. I now use two methods:
- Bonjour: Every peer listen for every bonjour request on the network, on the webpage I make a request to https://soundsync-UUID.local/. The peer then extract the UUID from the request and connect
- TLS Server Name Indication: I use sslip.io to connect to https://UUID_IP.sslip.io/. This is redirected to the local network IP of the peer which use the full domain name in the TLS handshake to extract the conversation UUID. This method doesn't always work because of some router filtering out DNS records resolving to 192.168.X.X.
All this process is very hacky and doesn't always work but I haven't found anything else better. We still don't have a good way to make self-hosting easy for anyone while making it secure and not dependant on an external service.
Edit: Just to clarify, I meant because an Electron app could be coded to allow a self-signed certificate, or allow AudioWorklets over http, or whatever other solution makes sense for your use-case.
Enterprise browsers will no doubt continue to perform CA verification by default, and I expect a preference will be offered to let home users (rare) and enterprise profile management (common) override this to enable/disable as needed for whatever custom localnet definition they require.
No other solution can work here, as by definition anything in localnet can neither be verified by an external entity nor issued in any trustable or permissible manner that is resilient enough for home users to configure, navigate, and manage on their own.
This is a predictable outcome of HTTPS Everywhere, and all major browsers have chosen to not yet deliver this for simple https://whatever.local requests, as tested in each of them today. While technically local network traffic might need as urgently need to necessarily be HTTPS to keep users safe in a home scenario, browsers further narrow the list of HTTP-offered features each year, and with the advent of HTTP/2 and HTTP/3 requiring mandatory TLS, the ancient status quo that's being delivered no longer meets the needs of modern networked homes.
I encourage the major browsers to step up and define their direction forward in coordination with each other, so that further wreckage is not introduced into the home networking ecosystem. The lack of progress here is indirectly harming users by teaching them that "http:// is fine if something says it is"; as is well understood, the judgement of whether to wire-encrypt or not cannot (by default) be entrusted to end users following instructions.
If there are existing discussions underway by any of the major browsers, I'd love an opportunity to learn more about them from links or stories shared in this discussion.
Nobody in the industry wants anything locally-hosted by end users to work well. Locally-hosted means not "cloud"-hosted. That means no sweet, sweet recurring subscription revenue stream or centrally-stored user data to "monetize".
This doesn't work for things like routers and modems that need to be configured before you can even access the cloud.
I am capable of operating my own CA out of my home in a matter of minutes in order to solve this problem, yet even I consider it a waste of my time to do so. In-home transport encryption should not demand a burden from the user. To quote Brazil:
“Listen, this whole system of yours could be on fire and I couldn't even turn on the kitchen tap without filling out a twenty-seven B stroke six.”
One of the reasons I run OpenWrt is to avoid some of the undesirable crud of commercially-packaged routers. And the crud is getting much worse, especially with convergence with IoT, where there are conventions of often gratuitous (lazy and/or predatory) centralized dependencies.
OpenWrt seems to have a good amount of civic-minded volunteers using it, not only driven by router manufacturers doing versions for their devices (where there are a lot of unfortunate commercial pressures to grab all the intimate data they can, create dependency/engagement/subscriptions/etc.). So I suspect there are others who are reluctant to do this like a move-fast-and-break-things conventional IoT play, even if that can be convenient in some ways.
Personally, for now, I currently just make my own self-signed TLS cert for the OpenWrt router's Web admin console. Longer-term, I want to make a dedicated hardware console for it. I don't expect everyone to do that, though, but I can imagine reasonably usable near-term solutions for bootstrapping a self-signed cert, integrated with the existing OpenWrt first-time config procedures, which would be easier than the bigger barrier of first-time firmware installing on a lot of the devices.
As a bonus, it seems to generate the certificate based on a random seed at boot time. So if you power it off for long enough, it generates a new different self-signed certificate that causes un-click-through-able security warnings in all browsers other than IE11.
For Safari, I can at least delete the saved certificate from the keychain and get the usual "untrusted certificate" warning which I can click through instead of the hard stop "impersonation" warning.
The kicker is that you can't even do anything other than reboot from the modem status page. It doesn't even expose a firmware upgrade; that's controlled by the ISP.
It's really annoying that the only way to provide secure HTTPS is to make your local devices dependent on a public service and abuse DNS resolution.
Hopefully as more and more people encounter this problem, some router-based certificate signing protocol will become known and accepted, maybe even with some kind of extension to DHCP to allow advertising the root cert of the router. Of course, a lot of care would need to be taken to make it hard to accidentally trust some cafe wi-fi...
This is a bug in those browsers, then. It's totally fine to use the system certificate store as a default, but it should be possible to trust other certificates at a more localized level - perhaps for a limited time, but not in a way that's limited to a single browser session.
I personally believe this is because so many users are stuck with old Android devices where the store is no longer maintained. Folks like Let's Encrypt are unable to get a foothold[2], with so many decaying unmaintainable operating systems out there. Chrome & every other app doing 3rd party HTTPS have to start creating their own root certificate stores that they can maintain, since the dead operating system on such a vast % of devices will not. Tragic situation, in my opinion, and with so few unlockable phones, buyers have limited ability to maintain or repair their own devices.
[1] https://www.chromium.org/Home/chromium-security/root-ca-poli...
- HTTP access, insecure and some browser functionality is unavailable for pages/SPA's served over HTTP.
- HTTPS and tell the user (maybe in a previous HTTP page before a redirect) to dismiss the browser big warning.
- Custom iOS/Android/Desktop app to access it, using an encrypted protocol
There is a (defunct?) W3C group working on this problem:
So if Chrome wants to piss off the Alpha Geeks in an organization, the folks who decide what software is used, not allowing any kind of override is a good way to do it.
Training people to ignore warning messages is clearly worse than just using http and letting the browser respond by disabling some features for safety.
It would be nice if they all came with a VTE that worked over bluetooth. Windows used to come with it's own VTE for dialing modems so obviously users can handle it.
> - HTTPS and tell the user (maybe in a previous HTTP page before a redirect) to dismiss the browser big warning.
That's not really true though, right? I think the options are actually:
- HTTP access, insecure and some browser functionality is unavailable for pages/SPA's served over HTTP.
- HTTPS, insecure and tell the user (maybe in a previous HTTP page before a redirect) to dismiss the browser big warning, but some more web APIs work.
Unless I'm mistaken with a self-signed cert you gain none of the actual security guarantees of https with a CA mostly stemming from the fact that there is no authenticity and MITM is trivial. I think it's a bad idea to pretend to a user that a connection is secure if it actually isn't. The solution I think would be to open up web apis to local http connections and create a verification system for self-signed devices like signal, matrix, and probably other systems have.
- "Not secure" for HTTP
- "Low security" for HTTPS encrypted but not authenticated (MITM still possible)
- "High security" for HTTPS encrypted and authenticated
... oh wait. https://tools.ietf.org/html/rfc6698
Every IoT device doing this might be annoying for Let’s Encrypt, but routers I think are worth it considering they stand guard for the rest of the home network.
Disclosure: we implemented this approach in a project I work on and...so far so good.
Yeah, that's not going to work.
The CA/Browser Forum has clear guidelines on the validation/verification methods required before a certificate can be issued and you're not going to find a CA that will allow something like this (even from a subordinate CA because, as TFA points out, they are responsible for all issuing performed by their subordinates).
Folks have been trying to come up with a good solution for this for ages and one hasn't been found yet. At present, I think the best solution is to just create your own private PKI and issue your own certificates. If you don't want to deal with that, you can use ACME with DNS-based validation to get a certificate for your desired hostnames (every 90 days).
Keep the goofy ssh key based dns registration and provide users with a SSH-hash.luci.openwrt.org A record pointing to their public IP, then just let LE and ACME do the rest.
Mikrotik's RouterOS (and I'm sure other commercial router distros) already provides me this in the form of <stringOfHex>.sn.mynetname.net (though I have to do the ACME myself via script or from a host inside the network).
This presumes you only have one OpenWRT-device and that it’s on a public IP.
To mitigate issues while the refresh is happening, the DNS server running on the router could intercept requests for its own name. Of course that doesn't work if the client on the LAN is pointing directly to an off-LAN DNS server, so it's not a perfect solution. But presumably, with a low A-record TTL, "downtime" of the local DNS name could be kept to a minimum, and the cert renewal could be scheduled to take place in the middle of the night.
Not sure if any of this process would violate LetsEncrypt's policies and get the account banned, though.
https://certbot-dns-cloudflare.readthedocs.io/en/stable/
I use this in my own setup. When letsencrypt provides a DNS challenge, the cloudflare plugin will complete it. The only requirements are
(a) owning a domain (b) having cloudflare control it (c) somewhere to run the certbot renewal cron job
If you don't like b, you can swap out cloudflare for any of the other DNS providers. I chose it because it's free.
For devices which can't run certbot (e.g. a managed network switch) I run certbot on a raspberry pi and use a deployment hook to deploy it. The code for deploying to a tp link switch is open source:
the web page can default to http, then on the top of that page advise users to choose https-with-browsering-warnings (provide a link for that for immediate use) that is safer for local use. the default still be http.
most of the routers are wireless with wpa2-psk which is encrypted. If someone knows how to use the shared-psk to decrypt http traffic and you need defend that, you already know you should use the https option.
From there a simple flood of ARP packets will allow the attacker to take over your network traffic and listen in on any unencrypted traffic, using the router admin password as an escalation within the network infrastructure.
Of course, such an attack is unrealistic in a home network scenario. It doesn't matter, because most consumer routers probably contain some unauthenticated RCE or authentication bypass anyway. Consumer routers aren't the most secure products and nearly every time a security researcher starts digging into their firmware, something spectacular comes out of it.
> This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks.
The BRSKI document does quite an robust imo job outlaying the environments & challenges & constraints folks like OpenWRT face in trying to set up devices.
BRSKI presents a specific approach, which no, does not immediately seem super useful/simple enough for openwrt. A devices (Pledge) contact a Manufacturer Authorized Signing Authority (MASA) Service. The MASA returns a Voucher that points it to a Join Registrar (& Coordinator), which the device uses for Enrollmemt to the domain & Imprinting of the Domain's material & exchange of Local Identity. The standard also includes ways for the MASA to collect Domain information (so you can register your registrar) and to provide optional Ownership Tracking of devices.
Openwrt could become a MASA, users could host Join Registrar's for their Domains, & nodes could securely go get the root trust key they ought to from that Join Registrar. Since the Domain generated that key, if the device were to present it's https interface with that key or one derived from it, HTTPS ought work.
[1] https://datatracker.ietf.org/group/anima/documents/
[2] https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapp...
The only problem I see with that is that now you have to setup ci and automated build for a vast number of targets (which i'm not sure if exists already).
The public dns record would then have 192.168.1.1 as A record (or whatever the default is in openwrt)
And I wonder, is having the private key sufficient to eavesdrop on a SSL connection? If that was the case, this wouldn't help against attackers.
You could actively MITM passthrough with the private key on any version, because in this and most cases HTTPS is not mutually authenticated, so the OpenWrt server doesn't know it is talking to your eavesdropping system rather than the web client.
If anybody other than the subscriber has the private key they can (and should) revoke the certificate. With Let's Encrypt you can even trivially automate this, fetch the new build, extract the private key, do the ACME revocation call with the signature from that key as proof and the certificate is revoked.
This is also a violation of the subscriber agreement for any public CA, it's unlikely they'll do anything about that beyond revoking the certificate, but they might, especially if you keep doing this after being told not to.
Sounds like a fast way to hit flash storage's write cycle limit and corrupt the device. The devices that OpenWRT targets mostly have flash memory that have limited amounts of write cycles[1] before the memory fails.
You're never supposed to reinvent the encryption wheel - but this would be a use case for it.
That only helps against passive eavesdroppers. Without a way to authenticate the device, a man-in-the-middle can easily pretend to be the device and receive the password.