|
|
|
how important is https?
Sunday, December 29 2024
ESP8266s are wonderful microcontrollers. They're cheap, they connect to the internet, they're easy to work with, and they don't consume all that much power. But they have their limits. They don't have much memory, so using https with them is a bit of a stretch. And if they're acting as https servers, then you have to somehow get them to serve certificates, which then have to be updated every year or two, which means that at some point the ESP8266 stops working until it is reflashed (unless you're proactive, something you're unlikely to be about your ESP8266 devices). It's all too much of a bother for me, especially considering what little you are actually getting with https. Sure, it's secure, in that it keeps people from spying on or manipulating your data on the way to or from the server. But there's no reason for paranoia about such things for all web transactions. For example, anyone reading this website is (at least at the time of this writing) doing so via http, so sure, anyone could spy on the data or perhaps (if they were extremely motivated and somewhat talented) even manipulate it. But so what? This data has no privacy issues for either me or the reader. Similarly, I dont't care whether or not the Chinese know what the temperature in the cabin basement is or even if they know what devices I have decided to remotely turn on.
Obviously, though, it does matter to me whether or not random yahoos can turn on those devices or play around with the data in the underlying database, since that could cause mayhem. So even in the earliest ancestors of the ESP8266 Remote Control system, for example, ESP-8266 Micro Weather, I had a method to keep random people familiar with the backend URL and the data it accepts (which is, after all, published on GitHub) from junking up my weather data with digital vandalism. Each of my ESP8266s contain a secret word that must match one known to the server, and if it doesn't, then the backend refuses to store data. These days that secret has to be correct for it to record or present any state information at all, thereby thwarting the Chinese. Or perhaps not; all the communication is happening via http, not https, meaning the data is all being sent in plaintext on the public internet and could be spied on and even altered by malevolent actors. As I mentioned, implementing https on an ESP8266 is too much trouble. But I'm skeptical that it's a simple matter for someone to actually intercept or alter my http data. They would have to have access to my local network, the network where my virtual server resides, or some network it traverses on the way between them, and it's unlikely that anyone motivated to fuck with my data would also have access to any of those. A government or an internet provider could do this, sure, but what would the motivation be? The only people wanting to fuck with my data are incel-adjacent sociopaths typing on a sticky keyboard in a basement (you know who you are).
So using http is probably fine, though I've gradually become uncomfortable with something I've been doing since implementing my shared-secret-over-http security system: transmitting the shared secret in plaintext in the URL sent by the ESP8266. Doing so makes it trivial for someone who somehow happens to gain access to the traffic to my server to craft URLs that could be used to poison my weather data and even control devices. So last night, with the guidance of ChatGPT (with whom I'd been chatting about the dangers of using http and how realistic they might be), I implemented a simple XOR-based encryption scheme that uses another shared secret on both the ESP8266 and the server to reversibly encrypt the first shared secret so that it wouldn't be sent in plaintext. But I wasn't very happy with the result of the encryption; small changes in the scrambling key resulted in small changes to the encrypted data. Ideally, encryption creates something that is indistinguishable from noise (think about the result of even the most basic hashing function), and this was far short of that. If a lot of data were to be encrypted by such an algorithm, I have no doubt that an analysis of the resulting encrypted text would quickly break the encryption scheme. But in this case, I was only encrypting one shared secret just to keep it from being in plaintext.
But of course if the encrypted version of the key is always the same and transmitting it with the data is what the server needs to authenticate that data, then that encrypted key is just another key being sent in plaintext. Ideally, the key would work for one transaction and couldn't be used to authenticate subsequent ones. But for that to happen, both the server and the ESP8266 have to have access to some other data that is changing. An obvious candidate for this is time. So as part of the encryption that I was using to produce the encrypted version of the shared secret, I used an integer timestamp as a key. This worked fairly well if the time-based key I was using was one that truncated off the final couple digits. This was because the timestamp is the number of seconds since a fixed instant in history, and it frequently happened that it had incremented once or twice on the server between the time the data was sent by the ESP8266 and when it was received on that server. Sure, I could get around this by including the timestamp to be used for encryption with the data. But if I did that, that url could be modified to send any bogus data. I figured occasional decryption failures caused by timestamp mismatches would be an acceptable price for the time being.
By this evening, I'd decided to also use the checksum of the data being transmitted as another key in the encryption of the authentication password. That way, not only would authentication passwords timeout, but any modification to data being transmitted would also be likely to trigger an authentication failure. All of this was doable with a trivial amount of computing power on both the ESP8266 and the server. A cryptologist might laugh at these measures, but I consider them sufficient for the level of security needed in this application.
Meanwhile, of course, there is a web-based application allowing me to read data and perform remote control operations. Obviously, that's the kind of thing that probably should be protected by https, since there is a login system with passwords that result in cookies, all of which are transferred from my browsers to the server in plaintext, since I can't be bothered to pay for an SSL certificate. Maybe I'll live to regret it, but that's a different problem, and one not baked into the very nature of the system.
All that work with rudimentary encryption had me interested in simple cryptography from the dawn of mechanized encryption. I went down something of a rabbit hole reading about the German Enigma and the Bombe used by British cryptography experts (standing on the shoulders of Polish cryptographers and led by Alan Turing) to break its encryption. The key to doing this was the fomulaic nature of German military communications, which often contained at least one "Heil Hitler," and a fundamental flaw that made it so that no character can be encrypted as itself).
Today was unseasonably warm and ended with heavy rains, which sounded nice as I tried to drift off to sleep without any form of chemical assistance (lately my totally drug-and-alcohol-free day has been Sunday). It took awhile, but I eventually fell into a sleep that was plagued by bouts of intense sweating and interesting dreams. These had me as a 25 year old high school student hitchhiking to Riverheads High School with the help of an unknown African-American woman acting as a rideshare driver (an occupation that didn't exist in 1993).
For linking purposes this article's URL is:
http://asecular.com/blog.php?241229 feedback
previous | next |
