Hacker News Reader

Comment by greggman2 | Hacker News Reader

Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Someone needs to come up with a solution for that. Ideally one that works with free and open source projects and not just well funded companies.

View on HN

Found out there's a w3 working group trying to come up with solutions

https://www.w3.org/community/httpslocal/

> Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage.

Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology.

If we were using something like noise protocol, nobody would be saying that tiny devices are incapable of proper security at the transport layer. There's just no clear way to assess the validity of a self-signed cert in the browser given today's political constraints.

I'm not familiar with this problem, could someone explain? Thanks!

There is no problem. Routers can use a self signed cert.

Could you expand on that a little? What do you mean? Won't my browser complain if the cert if self signed?

Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate.

I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology.

Better protocols could be developed to allow a browser to trust a server without (all) the limitations of the current system.

My harebrained idea for this:

- let companies register a wild card domain in the .local (or a newlocal) namespace: .acme.local

- designate the acme company with the ability to issue certs that never expire for any name in ".acme.local" but the browser will refuse to use certs signed with that key for anything outside "*.acme.local"

pros:

- the acme company can now make equipment that the users browser can connect to over an encrypted channel with zero config on the user's part

- the equipment can live off the internet indefinitely

- if the acme company is breached, and their signing key is stolen, the attackers can only use that key to impersonate acme company, it doesn't allow them to impersonate any other domains

cons:

- the browser manufacturers don't care about this use case so its never gonna happen

- the cert on the device never expires... and can never be replaced automatically somehow. I think the only workaround is acme could enable users to load their own certs if they are so inclined, but that shouldn't be required.

You should only have to store the self-signed cert exception once, at least on a given device. Now, if you're being targeted by a state-sponsored actor they might somehow be able to get you onto a honeypot network within the 2-minute window between plugging in your router and making your first connection to its web interface, but for everybody else a self-signed cert that you accept once during initial setup should be plenty good enough.

Why do they have to use self-signed certs? Ship the device with a valid cert for $last_three_octets_of_mac_address.$vendor.com to the device, and print it clearly on the setup instructions. Typing in something like d63d15.ui.com isn't onerous.

The CA/Browser Forum allows certs up to 27 months - do routers sit on store shelves for 27 months before being configured? Do they even sit for 12 months? (Once they're online, they can renew their cert, possibly with the help of the vendor who can track the private key or something.)

No need for even that. TLS should have an extension which says "I don't know how to verify my identity, but send this data to vendor.com and then they'll verify my identity".

Vendor.com can then look at the opaque blob forwarded from their hardware and decide if they want to deligate trust to it.

That doesn't quite work, because the premise of accessing a router setup page is that your internet connection doesn't work yet. So your router has to be able to prove its identity to the client entirely offline.

(You cannot special-case "This server is untraceable", else a repressive government could blackhole that server and trigger the relaxed validation rules.)

That would require significant effort for the vendor to set up and most internet devices such as routers are an absolutely minimal cost device. Literally every cent counts in production and vendors rather remove some features than shell out the 2 cents extra to add another 64mb of storage.

Furthermore, this would require either not being able to change the IP for your device (bad) or sending information about the layout of your network to the vendor (I wouldn't trust them with that info).

Very few people care about this and the effort of maintaining a custom DNS and a CA certificate system (which, by the way, would need to be subjected to rigorous security testing) just isn't worth it.

Lastly, what's the point? Adding a little padlock isn't worth it if anyone can get a certificate for the router ip anyway. How do you ensure that the router connecting to your IP really has the mac address it claims? It only takes one person to get root on their router to invalidate the entire security system and given how somehow router vendors are still shipping command injection vulnerabilities, I wouldn't assume that they can prevent that as much as they'd like.

What I want is the option to give a router my own security certificate instead of the self signed one. Let me use my own CA or let me mess around with letsencrypt, split-horizon DNS and Selenium scripts if that's what I need. Consumers don't care about TLS on their router and this would be the cheapest option to solve it for prosumers.

We sell industrial equipment which will live its entire life (20+ years) off the internet.

Browsers and the people who sit on these committees are understandably more focused on their own use cases, but there really does need to be a viable certificate solution for small embedded devices, preferably works with mDNS too. I'm not going to hold my breath, but until this happens any/all IOT devices will remain largely insecure. Big co's (like my employer) can develop and deploy a custom solution, most companies cannot.

That's a little bit of a different problem, since the client end of the connection isn't the general public. (At least for industrial equipment.) The router problem is that you need a normal, unconfigured web browser to be able to access the router's config page.

The immediate solution that occurs to me is installing a private CA, possibly one with name constraints for the vendor, because private CAs aren't held to the same rules about validity. I'm curious why this doesn't work - is it just that the tooling needed to make it happen isn't polished enough for small vendors?

I'm guessing that internet of things devices are, by their name, on the internet and can talk to a CA. Yes, this will require some way to give them a real domain name, but you could either give them names on the vendor's site or encourage people to get a domain name for themselves.

Reply on news.ycombinator.com