Cryptography for IoT Hackers — Part 1 of 13
| Part | Title | Status |
|---|---|---|
| 1 - You are here | What TLS Actually Does (And Why Your IoT Device Needs It) |  Published |
| 2 | Certificates From Scratch The Trust Chain Nobody Explains | Published |
| 3 | Setting Up Your Own CA and Issuing Certs with OpenSSL | Published |
| 4 | ESP32 + TLS: Your First Secure MQTT Connection | Published |
| 5 | What the TLS Handshake Looks Like on the Wire (Wireshark Lab) | Published |
| 6 | mTLS When the Server Also Checks YOU | Published |
| 7 | MITM Attack on a TLS IoT Device - What Breaks and What Doesn't |  |
| 8 | Cert Pinning The Fix, and How Attackers Bypass It | |
| 9 | Embedded Crypto Pitfalls: Hardcoded Keys and Weak RNG | |
| 10 | Breaking mTLS: Stolen Certs and Certificate Confusion | |
| 11 | Secure Provisioning How to Get Certs Onto Devices Safely | |
| 12 | Building a Hardened ESP32 TLS Client Checklist and Final Lab | |
| 13 | Secure OTA Updates Why Your Update Channel Is an Attack Surface | |
First - What Actually Happens When Your ESP32 Sends Data?
Your ESP32 is connected to WiFi. It reads a temperature sensor. It sends that reading to a server somewhere.
Simple, right?
But here is the thing most people never think about. WiFi is radio waves. Those packets your ESP32 is sending - they are flying through the air. They pass through walls. They go through your neighbour’s house. Anyone nearby with a laptop and the right software can literally sit there and capture every single packet your device is sending.
This is not theoretical. This is real. The tool is called Wireshark and it is free. I am going to use it in a later lab in this series and show you exactly what this looks like. You will see the data. Plain text. Readable. Scary.
So the question is does anyone nearby actually get to read those packets?
The answer is: it depends on whether you are using HTTP or HTTPS.
HTTP vs HTTPS The Simple Truth
If your ESP32 is sending data over plain HTTP yes. Anyone nearby can read it. Every byte. Your sensor data, your device ID, your passwords, your API keys. All of it. Readable like a text message.
If your ESP32 is sending data over HTTPS the data is encrypted. Even if someone captures your packets, they see garbage. Random characters. Useless without the key to decrypt it.
HTTPS = HTTP + TLS.
TLS is the layer that makes it secure. That is all TLS is a security layer that sits on top of your normal network connection and does two things:
- Encrypts your data so nobody can read it in transit
- Verifies who you are talking to so you do not accidentally talk to a fake server
That second point is the one most people miss. And it is the one that causes the most IoT security disasters. We will get to it in a minute.
What Is Encryption, Actually?
I know some of you have heard the word encryption a hundred times and still do not have a clear picture of what it means. Let me fix that.
Imagine you want to send a secret message to your friend. You both agreed beforehand on a simple rule: shift every letter forward by 3. So A becomes D, B becomes E, C becomes F, and so on.
You write: ATTACK AT DAWN
After encryption it becomes: DWWDFN DW GDZQ
Now if someone intercepts that message mid-delivery, they just see gibberish. They cannot read it. But your friend, who knows the rule, can reverse it and read the original.
That is the basic idea of encryption. You transform the data using a secret rule (called a key) into something unreadable. Only someone who has the key can reverse it.
TLS does this but with much more sophisticated math. Instead of shifting letters, it uses algorithms like AES. And instead of a simple shared rule, it uses a key that is negotiated freshly for every single connection, so even if someone captures today’s traffic, they cannot use it to decrypt tomorrow’s.
But and this is important encryption alone is not enough.
The Problem Encryption Alone Does Not Solve
Here is a scenario. Your ESP32 connects to what it thinks is your server. The TLS handshake happens. Encryption starts. All your data is encrypted.
But what if that server is not your server?
What if an attacker set up a fake server with the same IP? Your ESP32 connects to it. The attacker’s server also does a TLS handshake. Also encrypts the traffic. Your ESP32 has no idea it is talking to the wrong server.
Now the attacker can:
- Read all your sensor data
- Send fake commands back to your ESP32
- Steal any credentials or tokens your device sends
- Crash your device by sending garbage responses
This attack is called a Man in the Middle attack MITM. The attacker sits in the middle between your ESP32 and the real server. Your ESP32 thinks it is talking to the real server. The real server does not even know what is happening. The attacker reads and controls everything.
This is not theoretical either. We are going to perform this exact attack in Part 7 of this series. You will see it happen live.
So how does TLS solve this? How does your ESP32 know it is talking to the real server and not a fake one?
The answer is: certificates.
What Is a Certificate?
Think about a government ID card. Your passport, your driving licence, your national ID.
Anyone can make a fake ID at home. Print it, laminate it, done. So why does a fake ID not work at the airport?
Because the airport security is not checking you. They are checking the issuer. The passport was printed by the government. It has security features holograms, watermarks, special paper that cannot be reproduced at home. Security checks those features against what they know a real government passport looks like.
A TLS certificate works the same way.
A certificate is a digital document that says: “This server is who it claims to be.” But anyone can make a certificate. I can make one right now on my laptop in 30 seconds using a free tool called OpenSSL.
So the certificate by itself means nothing. What matters is who signed it.
The Certificate Authority - The Trusted Stamp
When a certificate is signed by a trusted third party, it becomes trustworthy. That trusted third party is called a Certificate Authority, or CA.
Think of the CA as the government passport printing office. They have a stamp. Their stamp is unique and cannot be forged. When they stamp a document, everyone who sees that stamp knows it is legitimate.
When a server wants a trusted certificate, it goes to a CA, proves its identity, and the CA signs its certificate with that stamp.
Now when your ESP32 connects to a server, the server sends its certificate. Your ESP32 looks at that certificate and asks one question:
Was this signed by a CA I trust?
If yes - connection proceeds.
If no - connection rejected. Hard stop.
But wait how does your ESP32 know which CAs to trust? It is a tiny chip. It cannot call the CA on the internet every time it connects to something.
The Booklet of Trusted Stamps
Here is the elegant solution.
Before your ESP32 ever connects to anything, you flash the CA’s certificate directly onto the device. Into its flash memory. It sits there permanently.
When the ESP32 connects to a server and receives the server’s certificate, it checks that certificate against the CA certificate already stored inside it. Locally. No internet needed. No phone call to anyone.
It is like giving the ESP32 a booklet of trusted stamps before it leaves the factory. Whenever it sees a certificate, it checks the stamp. If the stamp matches something in the booklet trusted. If not rejected.
This is why it matters which CA cert you flash onto your ESP32. If you flash the wrong one, or none at all, your device is blind. It will trust anything. Including the hacker’s fake server.
What Happens Without Certificate Verification?
A lot of beginner ESP32 code and unfortunately a lot of production IoT code too skips certificate verification entirely. The developer just wants it to connect quickly, so they set a flag that says “skip cert check” and move on.
This is one of the most common and most dangerous IoT security mistakes.
Without certificate verification, your device will connect to any server that responds. Real server. Fake server. Attacker’s laptop. Does not matter. It will happily do the TLS handshake, encrypt all its traffic, and send everything to whoever is listening.
The traffic is encrypted but you are encrypting it for the attacker. They have the key. They can read everything.
We are going to see exactly this in the attack labs later in this series.
So What Does TLS Actually Do? The Simple Summary
Let me bring it all together.
TLS does two things:
1. It encrypts your data in transit.
Nobody can intercept your packets and read them. They see gibberish. This protects your sensor data, your credentials, your commands everything that travels between your ESP32 and your server.
2. It verifies you are talking to the right server.
Using certificates signed by a trusted Certificate Authority, your ESP32 can confirm the server is legitimate before sending a single byte of real data. This protects you from MITM attacks.
Without TLS your data is readable by anyone nearby.
Without certificate verification your data goes to whoever responds first, real server or attacker.
With proper TLS your data is encrypted AND it goes to the verified, legitimate server only.
That is it. That is what TLS does.
What About the TLS Handshake Details?
You might be wondering what exactly happens during that handshake? The ClientHello, the ServerHello, the key exchange, the cipher negotiation?
We are going to save that for Part 5 of this series, where you will fire up Wireshark and watch the handshake happen live on the wire, packet by packet. By that point you will have already built a working TLS connection on your ESP32, so seeing the packets will make complete sense.
For now, the important thing to understand is: the handshake is a setup phase. Two things get negotiated:
- Identity the server proves who it is via its certificate
- Encryption keys both sides agree on the keys they will use for this session
After the handshake, the real encrypted data transfer begins.
What’s Coming Next
Now that you understand why TLS exists and what it is protecting you from, the next step is to understand certificates more deeply.
Where do they come from? What is actually inside one? What is a certificate chain? What is a root CA vs an intermediate CA? Why does your browser trust thousands of websites automatically?
All of that is Part 2 Certificates From Scratch: The Trust Chain Nobody Explains.