There's no HTTPS for the Internet of Things

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 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 “”, while there are tens of thousands of home Internet gateways that have the address “”.
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 “” 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.

An error message in the browser warning of an unsafe SSL connection

Why is that message generated? Because no reputable Certificate Authority will issue a cert, the manufacturer has self-signed it.

An untrusted SSL certificate

So I can ignore all those scary warnings and proceed. Right?


Why is this a problem?

I tried to connect to my IP camera via https:// only to get this error.

An SSL certificate which expired in May 2017

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
  • I connect to their API
  • 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.

15 thoughts on “There's no HTTPS for the Internet of Things

  1. says:

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

  2. We’re not there yet, but if everyone had their own domain name, devices could have “real” addresses (eg. 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

    That address could easily be a subdomain off something you already own – for instance.

  3. says:

    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.

  4. 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).

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

    1. says:

      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.

  6. […] Here’s a fun security question to answer: I have no idea what Terence Eden does as a day job, but every time I’ve seen him, he’s experiencing the challenges of a smart home and eloquently explaining them. One of his recent posts caught my eye because it’s a good question to ponder as we’re seeing more devices lose manufacturer support thanks to shutdowns or simply an unwillingness to carry on with a particular device. He asks why there’s no HTTPS for the internet of things. Specifically, one that users can control. (Terence Eden’s Blog) […]

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

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

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

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

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

Leave a Reply

Your email address will not be published.

%d bloggers like this: