There's no HTTPS for the Internet of Things
IoT NaBloPoMo network security · 16 comments · 600 words · read ~1,368 times.
Me being grumpy and stupid again.
I have an IP Camera on my LAN, I want to connect to it via HTTPS. I can't. Why is that?
Why do this?
I have a username and password to access my IP camera. And my TV. And my lightbulbs. And all my networked gadgets. If I try to enter the passwords on a modern browser, I get this error message:
It is now an accepted fact that data should be encrypted during transport - even on a trusted network.
I have a modest home network of several dozen gadgets - all chattering away over Ethernet and WiFi.
Ideally, they are all isolated and under my control - but hackers could break in, or an automatic firmware update could compromise them, or someone could plug something in to my homeplugs.
In short - I want to access 192.168.0.123 via a secure and encrypted connection.
Why it is impossible
The Certificate Authority / Browser Forum are the people who set the policy for how SSL Certificates are issued. They prohibit generating SSL certificates for Reserved IP Addresses - like the ones on your LAN.
Their explanation is:
Only one logical host on the Internet has the IP address “97.74.42.11”, while there are tens of thousands of home Internet gateways that have the address “192.168.0.1”. The purpose of certificates issued by publicly trusted Certification Authorities is to provide trust in names across the scope of the entire Internet. Non‐unique names, by their very nature, cannot be attested to outside their local context, and such certificates can be dangerously misused [...] issuance of certificates for non ‐ unique names and addresses, such as “www”, “www.local”, or “192.168.0.1” is deprecated CA/Browser Forum - Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses
Is there a work-around?
Sort of! Some IoT devices have self-signed certificates. if you try to connect to them via https:// they will present the certificate - but the browser will put big scary warnings in place.
Why is that message generated? Because no reputable Certificate Authority will issue a cert, the manufacturer has self-signed it.
So I can ignore all those scary warnings and proceed. Right?
WRONG!
Why is this a problem?
I tried to connect to my IP camera via https:// only to get this error.
The manufacturer doesn't do firmware updates so I'm left with a weak, self-signed certificate, which expired earlier this year.
If I tell my browser to ignore the warnings - what are the consequences? If something takes over that IP address (a malicious Internet Connected Fridge) - will I know?
Outsourcing Responsibility
There is an alternative - but it is almost too dreadful to consider.
I could rely on the manufacturer to provide a secure gateway to my devices.
- My IP toaster can make a secure connection to
https://toasty-mc-toastface.biz - I connect to their API
https://toasty-mc-toastface.biz/api/toaster/ - I then use the external API to control my devices
Yuck! Do you trust the Kickstarted company which provided your IP Toothbrush to stay in business for the lifetime of the product? Ha!
Do you trust them not to get hacked?
Do you want to deal with the latency between your home and the Windows Vista box in China which acts as their server?
Sadly, this is how devices like Alexa work. They don't connect directly to your kit, they go via an intermediary.
How to fix it?
I have no idea! If you do - please stick a comment in the box.
Should you use Let's Encrypt for internal hostnames?
The manufacturer self-signs their own CA internally
The manufacturer creates a cert for each device, and injects it into the device in the factory
User authorizes the manufacturer's CA only to sign only certs for domains under *.internetfridgeco.local (I have no idea if this is possible - I can't see a reason why it'd be impossible in a purely technical sense though) (You need to get the cert to the user somehow, but there's a few options of variable safety here: an email on purchase, publishing over bluetooth, downloading from real signed web portal in setup, etc etc) User browses to .internetfridgeco.local, gets cert that's trusted due to imported CA, has secure connection. With that done:
* Your traffic is encrypted
* You don't have to dismiss any big scary warnings
* Nobody on your network can take over that domain name (without giving a big scary warning)
* You don't need an internet connection to talk to your local device You do still have some more fascinating open problems though, like:
* If anybody can physically reach the device, they can probably pull the cert & private key from it (though that then still only lets them spoof that one domain)
* It's easy to open an avenue that encourages users to blindly trust new CAs, or which allows an attacker to provide their own CA here. Not unfixable, but needs careful thought.
* Certificate rotation is a hot mess if you want this device to be accessible forever
* Two companies could easily conflict in the X.local domain they want to use, since there's no central register whatsoever (unlike real DNS). The major issue though is that right now I don't think there's a well-supported way to import a limited-scope CA like this, and there's certainly no clear & reliable UX for your typical user to help them do so without also opening a huge risk to social engineering attacks tricking them into installing other malicious certificates.
Anon says:
Ultimape says: