Hacker News Reader

Comment by rogerbinns | Hacker News Reader

I keep hoping they will help address non-Internet TLS. For example if you run a HTPC, fridge, printer, device controller or anything similar on your LAN and want to talk to it over the same LAN using TLS. Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique.

Plex did solve this in conjunction with a certificate authority, but that solution only works for them. The general approach could work for others if someone like letsencrypt led the effort. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

View on HN

It's certainly possible to get a trusted certificate for a LAN-only device. DNS-based validation is your best option here. The only requirement is that you use an ICANN ("public") domain. This is not a requirement made up by Let's Encrypt, but rather by the CA/B Forum and applies to all CAs (for good reasons[1]!)

The Plex approach would be possible with Let's Encrypt, though you would have to find a way to avoid running into rate limits (via PSL or by making users use their own domains, which is admittedly only an argument if you're catering to a technical audience).

[1]: https://cabforum.org/wp-content/uploads/Guidance-Deprecated-...

An important point is that you need to own that public (sub)domain, even if it is only for use on a private LAN.

Not necessarily. As an example, an IoT vendor could set up a domain for their devices and delegate a subdomain to each device (basically what Plex does). They could also provide an API that allows those devices to provision a TXT record to solve the domain validation challenge. The actual ACME client would still run on the device itself, and validate using that API.

You'd need a way to get past the rate limits (either via PSL or with a rate limit exception), but other than that this is doable.

The fact that it would not be unique would fundamentally undermine the security of the CA system.

Nothing would stop someone from getting a certificate for the hostname "myfridge" on their LAN, then going to your LAN and using the same one to perform MitM for your "myfridge".

The plex approach is very interesting though! There would be a lot to think out, but LetsEncrypt could do it if anyone could.

Nothing would stop someone from getting a certificate for the hostname "myfridge" on their LAN, then going to your LAN and using the same one to perform MitM for your "myfridge".

Which brings up an important point that is often lost amongst the "encrypt everything!" "hype" prevalent today: you should be able to MITM the traffic of every device you own, or else you do not really own them and cannot tell what information they are actually communicating. Keep in mind that incidents like the smart TVs spying ( http://arstechnica.com/security/2013/11/smart-tv-from-lg-pho... ) were easily noticed because the data was in plaintext.

When pushing for more security, I think it is extremely important to be aware of all the consequences and pause to think deeply before we end up locking ourselves out of things we own, because by the time we realise, it will be too late.

You can still MiTM your own devices which use SSL, just add a custom certificate to them (all major MiTM tools support this).

The problem is not encryption... the problem is buying black box devices which are not transparent to their users. Bad manufacturers will always be able to do this whether we advocate for encryption everywhere or not.

> Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique

Connectivity [1] and using a global namespace are orthogonal things: you can use global DNS namespace just fine independent of connectivity. So from the naming perspective it Just Works if you get certs for printer.yourhouse.you.tld and fridge.yourhouse.you.tld.

(Of course you'd still like an automated cert renewal system for this disconnected case, but that's just a "simple matter of programming".)

[1] assuming by "LAN" you meant "network disconnected from the Internet"

By "you" I also meant people in general, rather than an individual tech person. Every connected printer, fridge, light switch etc user should have better security, and approximately none of them are going to set up global DNS space for their house!

I don't have any newish connected general purpose device (fridge printers, etc.... Do they give you an option to upload a cert?

My experience is that some may have self signed certs, or something similarly pointless, and that the vast majority have nothing so communications with them are in the clear.

If someone like letsencrypt helped solve the issue (probably in a manner substantially similar to plex) then the devices will be able to get and renew their own certificates automatically, and clients talking to them would just work.

The self-signed cert is not entirely pointless in this case. On your LAN, you can be fairly sure (or even ensure) that the first connection is secure. This allows you to accept the specific self-signed cert as valid and trusted. From then on, that's what you keep on trusting.

There's no CA to tell you that it's a valid cert for this specific location. But you're the owner and you're the authority in this case.

You are right in theory and in older times, but these days trying to get a browser to accept a self signed certificate is difficult. Remember that it would need to be done on a multitude of different platforms (eg Safari on iOS, Chrome on Windows) and by regular users. And no one is going to repeat this for the combinatorial explosion of browsers in the home with the devices (fridges, printers, other computers, device controllers, your garage door and what have you).

If you were a device manufacturer what would you do? One approach is to make all communication happen with "the cloud" as an intermediary, but that means that local operation is dependent on the Internet and some backend running on it somewhere. Or you have to come up with some hack, confusing instructions for users, lots of documentation etc. We see the results in Matthew Garrett's most recent post, and it isn't pretty.

I'm not saying it's a great solution. Just that it's not pointless to put a self-signed cert on a device like that.

What I'd do as a dev manufacturer? I'd try to change the game entirely. The current system simply did not have devices like that in mind. One idea would be "device certificates" - basically known CAs that can certify MAC addresses. This should be enough for local networks.

I think we can agree that self signed certs aren't useless in theory, they are close to impractical these days especially for folks who don't even know what one is, and are confronted by scary warning dialogs (if you are even lucky enough to see one!)

Amusingly mac addresses aren't as constant as you'd think. On my home lan I use a netgear wifi range extender. The way it works is to give fake (transformed) mac addresses for devices connected to it. For example if the real mac address is 11:22:33:44:55:66 when connected to the main access point, then when connected to the wifi range extender the rest of the network will see the mac address as aa:bb:cc:44:55:66. (The range extender also has ethernet ports - this affects wired and wireless connections to it.)

That's why I mentioned local network. Once we extend that with bridges, of course the verification fails. You can also assume any mac you want, so that's not a good security at all.

But that's all we've got. Unless we start integrating some kind of factory-sealed guaranteed-unique identity chips in all devices, there's simply no work around. Once something is on your network, you manage the identities. Either you have to manage some kind of CA, or trust whatever the factory provided you.

My wifi extender is the local network. That is why I mentioned you can't even trust a mac address on the local network!

I think this can be solved the same way plex did, by combining separate DNS space with a certificate authority issuing certs programmatically like letsencrypt does.

Amen! While it's possible to get certs for things like firewalls and other embedded devices, it's a big PITA. Factor in the short expiration times, and buying a 2-5 year cert becomes a lot more attractive for those use cases.

small note, since a while they are limited to maximum 3 years

For local traffic, why do you need a public certificate authority?

Because some devices and browsers have difficulty determining if they're talking to something on the local network or not. And they don't try to guess. So if your router requires you to connect via HTTPS, which is a good idea, have fun clicking past a nasty warning and then have nasty icons everywhere telling you that you're not secure.

And before you tell me to set up my own local authority and add it to the chain on every device ... common, really? Nobody wants to do that.

That's not a problem of browsers having a difficulty determining if they're talking to something on a local network or not, just because you're in a local network doesn't means you can't be victim of a MiTM.

Because every device and program uses more or less the same list of trusted root certs. Yes, you can install your own root cert and run your own CA for stuff like this, but it's a huge pain in the ass to actually install the cert on all your devices. Sure, you can put that cert in your Chrome trust store. But what about Firefox, Safari, IE/Edge? What about your iPhone with Safari and Chrome? What about curl/telnet? What about your daughter's tablet, your son's gaming rig, your wife's e-reader? It's all just so much work. Businesses that have in-house IT departments can get away with it because they provision hundreds/thousands of identical installs of the same software. You don't have that in your house or small office.

Because browsers have a UX for certs that's designed around the common/high-risk case e.g. average users going to banking websites, and deliberately terrible UX for self-signed certs.

Compare with SSH, which prompts to save the fingerprint on first connect, and warns loudly if the fingerprint changes. This is a superior way to handle self-signed certificates.

Presumably dhcp should tell you a CA for .local or similar?

Reply on news.ycombinator.com