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.
Thanks for post, will be following, weird nice timing too, funny that ;-)
Cheers
What are the chances an IoT device maker will make an updated firmware after 20 years? I think it really calls for making IoT devices open source.
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.
Please tell us what devices you posses that are more than 20 years old that are still in use?
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.
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.
C SDK uses gcc, so I don’t see an issue.
And we love C in embedded. ;)
mruby is writen in C
;P
Why would people throw C and all the millions of lines of code written in it (Linux kernel for instance) anytime soon?
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.
Still refuses to die.
COBOL is still processing the vast majority of financial data, by a very large margin…
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 :-)
I’d be lying if I said I wasn’t doing just that to use a old car ECU programmer.
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.
RichardP
Maximum of 20 years, depending when that root certificate was created, could be immediately.
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.
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)
To be fair, it was issued on 9/30/2000, so that’s even 21 years ;-)
My Coleman, Petromax and Aladdin kerosene and gasoline lamps will probably outlive me, the Li-Ion LED lamps most likely not.
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).
Why do these lamps connect to the internet?
Note that SPIFFS is being deprecated in favor of LittleFS…
my Esp https workaround is to use a php script on a webserver to convert http request to https connection.
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.
“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”.
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 :)
HTTPS on ESP8266, save yourself a HUGE amount of trouble, and just get an ESP32. They’ve been nothing but https trouble for me (http, they do fine)
That didn’t last long… Major players forcing 1 year certificate validity, see last paragraph in this weeks security news.
https://hackaday.com/2020/07/03/this-week-in-security-palo-alto-scores-a-10-cursed-images-vm-escapes-and-malicious-music/
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?
How can all certificates for websites fit in only 170kB (from the 1st linked article)?!
Just download a few million onto your 6 GPU hashing rig and leave it running for a couple of weeks until you’ve unlocked the secret NSA seed key.
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?
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