Easy, Secure HTTPS With An ESP8266

Security has always been an issue with IoT devices. Off the shelf devices often have terrible security while DIY solutions can be complicated, needing recompilation every time a website’s fingerprint changes. [Johannes] wrote in to let us know he’s been working on a way to make HTTPS requests easier to do on ESP devices.

The normal ways to do HTTPS with an ESP8266 is to either use Fingerprints, or to use client.setInsecure(). Fingerprints require the user to know exactly which pages the ESP will connect to and extract the Fingerprints from each of those websites. Since the fingerprints change yearly, this means the fingerprint will have to be re-extracted and the code recompiled each time a fingerprint changes. The use of client.setInsecure() is, obviously, insecure. This may not be an issue for your project, but it might be for others.

[Johannes’] solution is to extract the trusted root certificates and store them in PROGMEM. This allows access to any web page, but the root certificates do expire as well. As opposed to the fingerprints, though, they expire after 20 years, rather than every year, so the program can run for a long time before needing recompilation. This solution also doesn’t require any manual steps – the build process runs a script that grabs the certificates and stores them in files so that they can be uploaded to the SPIFFS written to PROGMEM to be used during HTTPS requests.

He’s come up with a fairly straightforward way to have your IoT device connect to whichever web page you want, without having to recompile every once in a while. Hopefully, this will lead to better security for your IoT devices. Take a look at some previous work in this area.

34 thoughts on “Easy, Secure HTTPS With An ESP8266

    1. That will only work if the compiler, linker, etc. are still actively supported on whatever computers we will be using in 20 years. If the software development world finally gets fed up with C and its crippling issues (can’t happen soon enough) and deprecates it in favor of a safer language then you might be screwed. Of couse if Expressif goes out of business you will also be screwed.

        1. Car. Game consoles. Oscilloscope. Calculators. Wristwatch. Various small appliances like a coffee grinder, toaster oven, etc…

          Of course, most of those things are still usable after more than 20 years *because* they don’t need to connect to the internet.

        2. When you laser-beam focus on a minor aspect of a controversy, such as with your challenge, at best you miss the point and at worst you’re looking to self-congratulate with your strawman presentation.

          We know consumers will keep networked devices _as long as they function_. So will municipal departments.

          If you doubt there aren’t hundreds of thousands of HP4 networked laser printers STILL in use 25 years later, then you’re just opining on a topic you have very narrow perspective of.

        1. Of course the C language will someday disappear, if for no other reason younger generations love to reinvent and repeat mistakes. Look what happened to COBOL.

      1. You should probably keep a virtual machine image with all the tools installed for as long as you have the devices you built with it. Then you can spin up xp on x86 like it was 2001 whenever you want – although you might need to set the clock back :-)

      2. I think in far less than 20 years, IOT processing power would have moved on to the the point where standard SSL libraries become feasible. The solution above makes SSL a possibility today as opposed to just winging it on hope and a prayer.

  1. Many of my old Internet-going devices (especially old Android stuff) have been broken by the move to TLS 1.2 in the past decade. Even though certs could be updated, updating to new encryption protocols that will come out in future will be much more difficult.

  2. I was kind of hoping for an article about how to speed up SSL negotiation when you are using the ESP8266 as HTTPS server because it is slow as hell and probably the secureserver implementation is full of memory leaks and other issues as you can very easily crash destroy them with even just simple tools like Nessus, Nmap or rapidly connecting to the devices.

    Also don’t assume that all Root-CAs are valid for 20 years.
    Take a look at Letsencrypts root for example:

    9/30/2021, 4:01:15 PM (Central European Summer Time)

    1. Also called Tilley lamps, during an extended power outage they work great. The only concern I would have is from the thorium mantles (which were the original ones supplied up until very recently, there are modern ones that do not use thorium).

    1. Big security hole. If you have to do it with an intermediary, at least use a strong PSK suite (thus avoiding all expensive pk crypto), or just pin your proxy cert, that can be self-signed — no need for a publicly trusted one.

      1. “Insecure” should probably be qualified. It’s going to be data “in the clear”.

        But not everyone considers un-encrypted communication on the LOCAL network to be dangerous. Which isn’t the word you used, I know, but without qualification that’s how many folks interpret “insecure”

        If I have an ESP periodically sending data to my email, “through” an intermediary, I’m not going to have my ESP send password data. It’s just going to make an API request to my intermediary home server, over HTTP.

        The fact that my private “hub” accepts insecure data locally, then connects to the Internet, is very debatable whether it’s “insecure”.

        1. That’s the same reasoning behind Souliss: assume the local network is secure.
          That could have been true 30y ago. Today, not so much.
          And you can’t count on ‘common’ users not doing something stupid, like putting the intermediary in the cloud. Unless the protocol doesn’t allow that, like in my DomoNode: I use multicast, that gets blocked at every level outside of the local network.
          Unencrypted comms are too easy to tamper with. And sometimes even encrypted ones leak too much data (like cameras increasing the wifi traffic when something moves can leak “someone at home” even if the passive eavesdropper does not have access to the images).
          But you’re right. Security can mean many things, from integrity to privacy to avoiding physical harm.
          I just wanted to point out the fact that you can avoid a lot of troubles with minimal efforts: symmetric crypto is nearly free. And it’s a good idea to avoid connecting to “random” services with severely limited resources.
          Another aspect to speak of could be the normative one: here in Italy, every “computer” must be updated at least every 6m. If IoT devices fall in the definition of “computer” (I’d like to see an engineer and a lawyer debate it… bring a lot of popcorn!) then a lot of nodes are automatically illegal :)

  3. This is great! Previously on my ESP32 projects I manually downloaded the root cert in question and wrote a bash script to convert it to a progmem array.

    Yes, this project doesn’t solve all issues with using TLS on ESPs… but it makes it much easier. If the root cert expires, you just re-build and flash – why all the complaining?

  4. Why not put only one cert on the device, which is used to connect to a device that can proxy the connection to the internet? This way the IoT device need not know anything about internet PKI and just knows the ‘internet’ as that simple proxy?

  5. came across Johannes’ article earlier. I would hardly call it “easier”. A quick glance on his github shows one apparently needs about a million files to pull it off

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.