LWN: Comments on "OpenWrt and self-signed certificates"

OpenWrt and self-signed certificates

Divadeer — Wed, 04 Aug 2021 03:24:09 +0000

You have to add the certificate to the windows certificate store. There are several different "substores" to put it in. Do not put it in personal. Add it to the Trusted Root Certificates Directory. I just checked and chrome uses windows certificate store by default. So if it is trusted by your operating system then it will be trusted by chrome.

OpenWrt and self-signed certificates

immibis — Mon, 11 Jan 2021 19:17:19 +0000

The router *is* a switch. Here's a typical architecture (data flow from top to bottom, not all components shown)

User
↕
User's computer
↕
Wire
↕
RJ45 port on the router - stuff below this line is inside the plastic box that we call a "router"
↕
Ethernet switch <--> CPU <--> Internet port
↕
Wi-Fi access point
↕
Antenna connector - stuff above this line is inside the plastic box that we call a "router"
↕
other computers connected to Wi-Fi

In other words, the router's CPU does not get to intercept all traffic and therefore cannot prevent an ARP poisoning attack.
When you connect to 192.168.0.1 your computer first broadcasts a packet asking "what is the MAC address for 192.168.0.1?". If the first response it gets is *not* from the router's CPU, too bad. It will cache the MAC address of some other computer that maliciously replied. Then it has no way to know that that computer isn't the "real" 192.168.0.1. In fact, it might be the real 192.168.0.1 - how does it know you didn't change the router's address to 192.168.0.2?

And because the CPU is not in the path between your computer and other computers, it can't block that packet. Advanced switches support packet filtering but they wouldn't put an advanced switch in a home router, too expensive.

OpenWrt and self-signed certificates

vmsh0 — Sat, 05 Dec 2020 08:59:27 +0000

I argue that the automatic certificate deployment thing would make the devices *less* secure.

When using self-signed certificates, you have the option to ask the browser to add the self-signed CA to its internal CA storage. From that point on, if your computer doesn't get compromised, you have a very straightforward way to authenticate the device: if the web browser doesn't say anything, you're good.

With this new, complicated system, you would instead have to notice that the hash in the URL bar changed. The web browser will not help you anymore!

Not that the kind of device would be particularly prone to device substitution or man-in-the-middle attacks: typical OpenWRT systems are small and physically contained. But it seems pointless to add complexity (very bad for sustainability!) and enlarge the attack surface to remove a very small annoyance for "casual" users.

OpenWrt and self-signed certificates

Fowl — Sat, 05 Dec 2020 04:07:28 +0000

Once discovered (ie. almost immediately) such public “private” keys are revoked.

OpenWrt and self-signed certificates

akvadrako — Fri, 04 Dec 2020 18:19:51 +0000

The private key is shared publicly with all servers. This is just to trying to be better than HTTP.

OpenWrt and self-signed certificates

Fowl — Thu, 03 Dec 2020 23:38:12 +0000

You would then need to route/centrally re-encrypt the traffic too, otherwise you're leaking the private key.

OpenWrt and self-signed certificates

akvadrako — Thu, 03 Dec 2020 11:49:52 +0000

Or you could use Let's Encrypt with a wildcard DNS certificate. Then you could make a public domain which can be used for each local IP:

router.small-2.local.net A 192.168.2.1
router.big-2.local.net A 10.0.2.1

OpenWrt and self-signed certificates

Lennie — Mon, 23 Nov 2020 22:52:25 +0000

You touch on an other subject: old software and encryption, etc.

I'm very much for something like archive.org making old software run again so people can use it as it used to be used.

I'm amazed at what has been possible: https://archive.org/details/win3_stock

https://bellard.org/jslinux/vm.html?url=win2k.cfg&mem...

But as we've seen for example Apple had a service which was used to check developer signing certificates. These kinds of things will make it harder and harder to keep old software running.

And full disk encryption will mean a device which isn't in use anymore because someone dies the data might be gone.

The reason the dark ages are called the dark ages is because we didn't have much books/records from then. We might be entering (if not already have) digital darkages.

OpenWrt and self-signed certificates

Lennie — Mon, 23 Nov 2020 22:29:09 +0000

Yeah maybe, I don't know what they would allow.

None of it is ideal obviously.

OpenWrt and self-signed certificates

epa — Mon, 23 Nov 2020 14:22:54 +0000

What happens if you make a certificate not for a hostname but for a particular IP address like 192.168.1.1? That address is reserved for local networks and not routable on the Internet. To get to the site, you have to enter the IP address in the URI bar (it can't be used for a hostname, even if DNS is changed to return 192.168.1.1 for that name). The certificate issuer might be prepared to allow a shared certificate under these restrictions, and Mozilla and others might be prepared to accept it. Possibly the browser, rather than its usual secure padlock item, should show a warning and require an explicit step to view the page.

OpenWrt and self-signed certificates

mmonaco — Sun, 22 Nov 2020 17:02:27 +0000

This. This whole technical problem on the OpenWRT side seems like a workaround for browsers not having a similar, optional (?), TOFU model to SSH.

OpenWrt and self-signed certificates

isomer — Sun, 22 Nov 2020 15:27:22 +0000

This sounds very similar to what plex does: https://blog.filippo.io/how-plex-is-doing-https-for-all-i...

They issue wildcard certs for *.<hashofcert>.plex.direct, and then have a DNS rule that means that 192-0-2-1.<hashofcert>.plex.direct returns IN A 192.0.2.1.

OpenWrt and self-signed certificates

shx — Sun, 22 Nov 2020 10:24:13 +0000

I ran into similar issues but that turned out to be a problem with an malformed certificate create by an old Juniper. The unexpected new information was that still a lot of the browser TLS stack is bound to the TLS library shipped with your OS, which results in browsers behaving differently on different operating systems, especially Chromium based browser. Probably the most consistent experience has Firefox due to NSS and the root cert store they ship. But than again distro builds might differ.

OpenWrt and self-signed certificates

diamondlovesyou — Sun, 22 Nov 2020 04:52:42 +0000

MITM doesn't matter here though. HTTP (no S) also suffers from this issue but it isn't (currently) stopping anyone.

OpenWrt and self-signed certificates

LtWorf — Sat, 21 Nov 2020 17:33:55 +0000

It's not all bad… because of reasons I was using windows XP the other day, and basically internet is unusable because of https and severely old certs that are on XP. I installed chrome on it.

OpenWrt and self-signed certificates

NYKevin — Fri, 20 Nov 2020 22:55:52 +0000

There are multiple problems with that. Let's say there are three devices:

- The router, DNS server, and/or whatever device or combination of devices is handing out IP addresses and establishing DNS records (R).
- The end user's computer, laptop, or other client (C).
- The other device which C wants to securely connect to (O). O can be the same device as R, or a different device (e.g. a Raspberry Pi, an IoT device, etc.).

Then:

1. C must trust R, and bootstrapping that trust is a hard problem (i.e. it can be MitM'd during initial DHCP negotiation, if there are untrusted devices on the same network).
2. R must trust O, and bootstrapping that trust is also a hard problem (unless O = R).
3. As described in RFC 8375, DNSSEC is not designed for domains with local significance (such as home.arpa.), so you would need to configure C to use a custom trust anchor (probably R). There is no standard way to make this happen automatically, and I'm not even sure if the average device exposes a way to do it manually. DNSSEC is an absolute requirement for DANE.
4. DANE is an unnecessary complication. If R is willing to let O create DNS records, it should also be willing to sign a CSR which asserts that O owns those records, and (assuming we've gotten this far) C should be willing to trust the resulting signed certificate just as much as it would have trusted a DANE-based certificate. If you insist on breaking this into a two-step process, you can use some form of ACME to prove DNS ownership.

In my estimation, 1 and 2 are the "real" problems, and 3 and 4 are more on the side of nitpicky details.

Of course, you can just say "there aren't any evil devices on my network, so I'll just trust everything implicitly," but I don't think browser makers are willing to make that the default behavior. Lots of consumer devices are hilariously insecure.

OpenWrt and self-signed certificates

rknight — Fri, 20 Nov 2020 21:43:35 +0000

One thing that is apparently missing from the discussion and most of the responses is that OpenWrt is no longer just for routers. There is a surprising number of non-router devices currently supported by OpenWrt to include cameras, NAS devices and a recent addition switches.

OpenWrt and self-signed certificates

jo42 — Fri, 20 Nov 2020 20:35:37 +0000

At first, if these devices can't obtain a valid TLS certificate, they can never use QUIC.

And wouldn't it be possible to use DANE TLSA for this? When a host connects to a network it could ask the local router/DNS server to assign it's TLSA record to it's address and host name. So, if a hosts trusts the router and its DNS it could obtain the TLS fingerprints from this trust anchor.

OpenWrt and self-signed certificates

nix — Fri, 20 Nov 2020 18:38:15 +0000

Networked printers are another big one. With the shutdown of Google Cloud Print they are more or less all now restricted to direct HTTP(S), plus the usual IPP or whatever printing protocol.

OpenWrt and self-signed certificates

nybble41 — Fri, 20 Nov 2020 15:44:49 +0000

Technically mDNS can work across subnets if you configure a system connected to both networks to perform reflection (enable-reflector=yes and reflect-ipv=yes in the [reflector] section in avahi-daemon.conf), and if you want to manage local devices across multiple private subnets then you should probably do that. But yes, like most of the other proposals this would mainly be aimed at connecting to local devices on the same subnet.

It's not strictly necessary that the name end in .local, though. It could be expanded to include any name on the Public Suffix List, which would allow the use of dynamic DNS services or vendor-specific domains (as long as they register as public suffixes, which is a good idea in any case).

OpenWrt and self-signed certificates

mebrown — Fri, 20 Nov 2020 15:20:09 +0000

.local implies mdns and that works only on the same ip subnet, so this isnt a general solution, if I'm understanding the proposal correctly.

OpenWrt and self-signed certificates

mebrown — Fri, 20 Nov 2020 15:15:10 +0000

This opens users up to all kinds of man in the middle attacks. sharing certs between devices is a terrible idea.

OpenWrt and self-signed certificates

arnout — Fri, 20 Nov 2020 11:41:06 +0000

> Of course, this idea would not help much with OpenWrt, since it's usually added after the fact instead of coming from the factory.

In most cases, the devices are not sufficiently locked down to hide the private keys installed on them. So when installing OpenWrt, the existing keypair can be recovered from it, which allows the OpenWrt-based system to provide the same certificate and address.

Devices that are properly locked down will typically not allow OpenWrt to be installed on them at all (which is a GPLv3 violation, but those devices will typically not have any GPLv3 on them).

OpenWrt and self-signed certificates

Lennie — Fri, 20 Nov 2020 08:34:24 +0000

It would 100% need to be in agreement with the issuer.

And possibly the CA/B forum.

Almost but not quite

fulke — Fri, 20 Nov 2020 07:31:21 +0000

What about to print public key?

OpenWrt and self-signed certificates

tialaramex — Fri, 20 Nov 2020 04:53:18 +0000

And obtaining such a certificate with this intent is also a violation of your subscriber agreement. The issuer _probably_ won't do anything about that, but they're entitled to do so if they wish. Knock it off.

OpenWrt and self-signed certificates

Fowl — Thu, 19 Nov 2020 22:42:54 +0000

Such a certificate would be immediately revoked. This has been tried before.

OpenWrt and self-signed certificates

flussence — Thu, 19 Nov 2020 21:56:41 +0000

I should be able to unplug the phone line and still have access to devices on my LAN. This problem is the fault of browsers blindly mandating centralised security for a decentralised internet, and it should be the responsibility of browsers to fix it.

OpenWrt and self-signed certificates

davidstrauss — Thu, 19 Nov 2020 20:40:52 +0000

>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".

My understanding is that the constrained subordinate CA properties are not well supported by many TLS libraries. The lack of support even includes dangerous effects like treating the CA as unconstrained (despite the property constraining the CA being marked as mandatory).

OpenWrt and self-signed certificates

NYKevin — Thu, 19 Nov 2020 18:51:55 +0000

> Because OpenWrt is flashed to existing devices they're in a trickier situation, and maybe (if you aren't buying a device that's supplied with OpenWrt out of the box) the best way forward is to do that trust step during the flashing process?

If you have a direct, wired connection to the router, then the user should be able to physically verify the fact that it's a single cable and not e.g. a hub, switch, bus, or some other nonsense that allows multiple devices on the same segment. You can then establish trust over a link-local connection (or you can do actual DHCP over the wired connection first, if you really want to). This can be done at time of flashing or at any point thereafter.

Downsides:

* Requires the user to physically verify the network topology, which means it can't be fully automated.
* The user has to know what a "direct wired connection" means. This is a low bar for someone who is personally flashing their router, but it might be more of a problem for general consumers. There may also be social engineering attacks to consider. Plenty of people will set up an OpenWrt router once, and then hand it off to someone with poor technical skills (e.g. if you're setting up a family member's home network), so allowing this after the point of flashing may be a bad idea. OTOH, if you can't do this after flashing, then you have a problem if you ever need to re-establish trust from scratch (e.g. trust store accidentally deleted, hardware failure, etc.).
* If the device is simultaneously connected to the router over a wire and over WLAN, the browser or other trust agent must force a wired connection. This is doable on most systems, but might pose challenges if you want a general, cross-platform solution (even just on Linux, figuring out which network interface is "the right network interface" is an inconsistent mess in my experience). Alternatively, we need to disconnect from the wireless network altogether, or have some kind of OS-level support for this whole operation.
* Although many home networks do have a PC permanently wired into the router, this does nothing for any of the other devices on the network, which might be important if you have a laptop or something which has to trust the router. You would still need some kind of PAKE-like solution for expanding trust beyond that one PC. But at least you now have a means of generating and displaying a PAKE in a trusted fashion.

Overall, I am not thrilled with this idea, but I think it could work for situations where we know or reasonably believe that a technically proficient user is doing the initial setup.

OpenWrt and self-signed certificates

marcH — Thu, 19 Nov 2020 17:35:31 +0000

> In general, TLS seeks to establish authenticity in addition to confidentiality, but it's unclear what that means in the context of a home network. First, we need to establish a threat model ...

Thanks for laying out some high-level, conceptual issues and security requirements; something I wish the article had started with instead of the implementation details.

About the project itself I understand people love to code but I think it would avoid confusion and disappointments to discuss, clarify and publish the basic security requirements and objectives before sketching some new "on-the-fly PKI" system. These questions are indeed relevant far beyond OpenWRT and other comments here have unsurprisingly mentioned other efforts outside OpenWRT to solve the same issues.

I'm afraid they are only two high-level approaches to prove who you are on the Internet: centralized Public Key Infrastructure (https,...) versus peer to peer (ssh, PGP, self-signed https,...) So the very first question OpenWRT should answer is which approach it wants to support? Both? It should be obvious that you can't bootstrap a centralized approach without network access, no need to get lost in the implementation details to realize this.

Another very important question is indeed: does an OpenWRT router really want to prove who it is? Or just encrypt with an understood and accepted MitM security risk? Give the user the choice?

Another one: why can we choose "Yes, I will keep trusting this ssh server until further notice" on the very first connection attempt but not do the same with an https browser? Leading to awkward "solutions" like tunneling https (and other things...) in ssh, our security swiss army knife? For the record I set up my OpenWRT router with a back to back cable totally disconnected from everything else.

It's great OpenWRT developers look at these questions. It's not great they seem to look at them in the narrow scope of the OpenWRT code.

OpenWrt and self-signed certificates

excors — Thu, 19 Nov 2020 17:31:16 +0000

Apart from routers, are there a significant number of IoT devices that care about being directly accessible from a web browser? In the ones I'm aware of, pretty much all the communication between user and device is:

* Over wifi where the IoT device behaves as a WAP, and a mobile app temporarily connects the user's phone to that WAP and communicates using some arbitrary protocol (maybe HTTPS, maybe not)
* Over BLE, where a mobile app connects the user's phone to the device with some custom protocol (definitely not HTTPS)
* Through the cloud. The device connects outwards to a cloud server via wifi, or via some short-range protocol to an internet-connected gateway device. The user connects to the cloud with a web browser or mobile app or whatever. The cloud passes messages between user and device.

Web browsers are only relevant for the last of those, and they're just connecting to a regular cloud web server which can use regular CAs. The device only connects to a custom app or to a custom cloud server, which can authenticate the device using a custom CA.

It's not clear to me that a solution for OpenWrt would be of any relevance for other IoT devices, because they have no interest in being directly accessible over HTTP(S) anyway.

OpenWrt and self-signed certificates

nybble41 — Thu, 19 Nov 2020 15:59:33 +0000

You mean something like this? https://lwn.net/Articles/837676/

OpenWrt and self-signed certificates

Lennie — Thu, 19 Nov 2020 15:58:51 +0000

This might be the right answer.

Have a local name: local.openwrt.org which has a known certificate and which can automatically be downloaded/updated.

It's not more secure, but at least more convenient.

The DNS-server on the OpenWRT device would overwrite* the name with it's own IP and thus a DHCP-client when resolving that name would point directly that OpenWRT device.

* For example Unbound has the local-data option:

https://nlnetlabs.nl/documentation/unbound/unbound.conf/

OpenWrt and self-signed certificates

Lennie — Thu, 19 Nov 2020 15:52:54 +0000

Well... https://www.zdnet.com/article/chrome-will-soon-have-its-o... :-)

OpenWrt and self-signed certificates

cesarb — Thu, 19 Nov 2020 13:03:43 +0000

For the particular case of IoT devices which listen only on the local network, a possible solution would be to take inspiration from what Tor does with its .onion hostnames: each device would be provisioned at the factory with a self-signed certificate, and would have a sticker with a random-looking .local address, that address being actually part of a hash of the certificate's public key; the user would type that address to configure the device. Browsers would have to be modified to accept self-signed certificates for .local addresses whenever the certificate's truncated public key hash matches the address. Of course, this idea would not help much with OpenWrt, since it's usually added after the fact instead of coming from the factory.

OpenWrt and self-signed certificates

epa — Thu, 19 Nov 2020 12:22:27 +0000

Why not provide HTTPS with a single certificate shared between all OpenWrt devices? It's not particularly secure but it is not any worse than unencrypted HTTP. Again, it can be provided on the LAN interface only (and possibly restricted further, like only available when there is a single LAN client). Once initial setup is complete, a new certificate can be generated for HTTPS. The initial setup with a shared certificate would have to have a special hostname.

OpenWrt and self-signed certificates

LtWorf — Thu, 19 Nov 2020 10:36:28 +0000

Try accepting a self signed on chrome on winows… Last I tried I failed to do it and had to use firefox.

OpenWrt and self-signed certificates

ale2018 — Thu, 19 Nov 2020 10:03:22 +0000

> The CA model does not work for all use cases

This!

Public Key cryptography solved a technical problem. PKI didn't solve the "social" problem of making it understandable.

OpenWrt and self-signed certificates

PhilippWendler — Thu, 19 Nov 2020 08:46:33 +0000

That was also my first thought. There is no need for a subordinate CA, the "SSH-hash.luci.openwrt.org" idea can easily be used with Lets Encrypt itself. OpenWRT just has to provide a DNS service for this domain that allows everyone who proves ownership of the corresponding private key to edit that DNS record. Then ACME with DNS authentication can be used, which works as soon as the router can send DNS and HTTP requests to the internet. So like all other solutions, it might not help for the first initial setup, but at least the device does not need to be reachable from the internet, it can be done behind another router, for example. OpenWRT could even on its first boot send DHCP requests on its WAN interface, try to get an internet connection that way, and get a certificate. Then the installation instructions would just need to tell users to connect it to an existing router for the first boot.