There's no HTTPS for the Internet of Things
IoT NaBloPoMo network security · 16 comments · 600 words · read ~1,362 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?
I haven't thought this through carefully, but you could do something like:
Tell your system to trust certificates signed by the manufacturer Get them to sign and install on the device a certificate for it current IP address. Probably much better would be to use an IPv6 address, either local or global, because that's less likely to change. You then connect to the device directly using the new certificate.
This still relies on them producing updated certs, though. And in the end it fails because of the ease of spoofing IP addresses. It also assumes that you're only using the IP address to access it and not coming in from outside via proxy or something.
A better solution would be to allow you to install your own self-signed certs on your device and tell your system to trust them...
We’re not there yet, but if everyone had their own domain name, devices could have “real” addresses (eg. toasty-mctoastface.edentshome.ninja) which CAs would have no problem issuing certificates for. DHCP is quite happy to hand out domain names to clients and properly integrated with your home router’s DNS service, you would end up not visitingn a private IP address, but https://toasty-mctoastface.edentshome.ninja
That address could easily be a subdomain off something you already own – https://toasty-mctoastface.home.shkspr.mobi for instance.
Not sure if it's immediately practical, but theoretically there's a reasonable route that looks like:
The device is built to a local MDNS domain like .internetfridgeco.local
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:
Say your toaster’s globally routable address is 2001:db8:1234::f00d. Get your toaster a domain name that it can update dynamically. Then open a hole in your firewall to allow incoming connections to 2001:db8:1234::f00d. Then have the toaster request a domain name from LetsEncrypt.
Now you can access your toaster securely.
Unfortunately this couldn’t be done in a fully-automated manner, and your toaster is now listed on Shodan (and therefore liable to start printing obscene images on your toast).
This might be useful. Must get my IP6 routing going again and try it...
https://ip6.name
I think letsencrypt should work with one of these names...
The fix is not easy but it involves decentralizing certificate issuance + IPV6. Every network need a unique domain name system using a tool like namecoin or ethereum name project. So you'd have something like ipphone001.iotdevices.youruniquehouse.tld pointing to your unique IPV6 address. Instead of a centrally issued public ssl cert you'd store a cert in your dsitributed DNS system. Now you can go to ippohon001.... and get to your IOT device and allow it to be only accessible on your local network still.
By moving to a global addressing scheme for IPs so every IP is unique, and taking the problems of centralized DNS and SSL certification you open up the ability to truly have SSL everywhere.
Ultimape says:
Plex had a similar problem with their home servers needing to be https. They had to do a lot of hoops to get it working https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ and might be too big of an ask from a central IoT vendor who's just trying to sell something internet enabled.
Ultimape: good to see you here on a random blog!
This is especially problematic for device manufacturers that produce gear for isolated networks. I like plex’s solution but it won’t work for the devices my company makes. Our customer’s (e.g. CNN, NBC, ABC, etc) entire facility is typically air-gapped from the internet and yet users need to connect to the devices using browsers.
There don’t seem to be any good solutions except possibly using self-certs & just telling users to click through the scary warnings… if that is even going to be possible in the future. Either that or reverting to fat clients and custom solutions.
I kind of wish more device type things had IPv6 plus a letsencrypt client built in. DNS record + tell it it’s own hostname and you are good to go. 🙂 I do just pay for certicates for a few things too.
ah, the days when I had a /24 (public) netblock of my own, for home… — but yes, this sucks. Massively.
I think baking in of the subscriber's username to part of the DNS name does some good stuff - a relying client can verify they're talking to *.rmc47.service.example, and the certificate issuing service can verify it only provides a cert to a device authenticated to that account.
I would love it if IoT had to publish interfaces to allow you to use with “self hosted cloud” (LOL) alternatives. I avoid cloud stuff for IoT as much as I can, and try to stick to MQTT. Pondering MQTT server and functions in @firebrickltd some time.
I think it's almost impossible: toasterGUID.iot.tld. Toaster has API key to update A to local IP & _acme-challenge TXT, toaster is able to issue a cert via an ACME DNS challenge, provided toaster has sufficient connectivity to the CA & to the API used to update the DNS.
Other people have mentioned setting up internal CAs - but for most folks this isn't a realistic option as things stand. If future home routers came with CA functionality built in and somehow automated the process, that could work.
@Edent variety of ways to solve this. Personally, I want to be my own local CA for my own network. So I would get an official domain name, say home.example, get a cert for it (eg letsencrypt) for my gateway device, but that cert would have the flag set that allows it to issue its own certs. I use that to issue CERTs die the devices on my network, all which get a dns name like temperature.home.example.
Lots of pieces would have to be made to work, but doable I think.