When you connect to a website over HTTPS, send an email, or push code to GitHub, you’re relying on a cryptographic protocol called Transport Layer Security (TLS). It’s a series of cryptographic techniques that ensure your data is private, authentic, and tamper-proof as it travels through networks filled with untrusted intermediaries.
For embedded and IoT developers, understanding TLS is essential. Whether you’re connecting a Wi-Fi-enabled sensor to a cloud API or sending logs to a server, TLS provides the foundation for secure communication. In this post, we’ll unpack how TLS works, why it replaced Secure Sockets Layer (SSL), and what actually happens during the “TLS handshake.”
Why We Need TLS
By default, protocols like HTTP send data in the clear (information is transmitted in plaintext). Anyone sitting on the same network (say, a public Wi-Fi hotspot) can eavesdrop on your packets. That means usernames, passwords, API keys, and credit card information can be read by anyone intercepting traffic.
The first step toward solving this is encryption. If both sides of a connection share a secret key, they can encrypt messages so that eavesdroppers only see gibberish. This is called symmetric encryption.
Symmetric encryption example:
- The client and server both know the same secret key.
- Each message is encrypted using that key.
- Anyone without the key sees random bytes.
Modern symmetric algorithms like AES-256 are extremely secure. Brute-forcing a 256-bit key would take longer than the age of the universe with current hardware.
The Key Exchange Problem and Asymmetric Encryption
But there’s a catch: how do the two sides get that shared key in the first place? You could mail it, call the server admin, or meet in person. However, this is clearly impractical for billions of web connections.
This is known as the key exchange problem, and solving it led to one of the most important breakthroughs in modern cryptography: asymmetric encryption (also known as “public-key cryptography”).
Asymmetric encryption uses two keys: a public key and a private key. The public key is freely shared with anyone, while the private key is kept secret.
Anything encrypted with the public key can only be decrypted with the private key. That means a server can publish its public key, and anyone can use it to send it a confidential message without ever needing to exchange secrets ahead of time.
SSL and TLS rely on both symmetric and asymmetric encryption to establish a trusted, encrypted channel between servers and clients. As we’ll see, asymmetric encryption is used to establish trust and perform a symmetric key exchange. Those keys are then used to create a fully encrypted channel where both ends can communicate freely without fear of eavesdropping or tampering.
The Man-in-the-Middle Problem
Asymmetric encryption solves the key exchange problem, but it doesn’t guarantee trust.
Imagine this scenario:
- You try to connect to example.com.
- An attacker intercepts your connection and pretends to be the server.
- They send you their public key instead of the real one.
- You happily encrypt your password with it.
- The attacker decrypts it, reads your credentials, then re-encrypts it with the real server’s key.
From your perspective, everything works fine, but your data has been compromised. This is called a man-in-the-middle (MITM) attack. Encryption wasn’t broken, but the authentication was. You had no way to confirm that the server was really who it claimed to be.
A Brief History of SSL and TLS
To address these issues, Secure Sockets Layer (SSL) was introduced in the early 1990s by Netscape. SSL 2.0 arrived in 1995, quickly followed by SSL 3.0 in 1996, which added key features like:
- Cipher suite negotiation: The client and server agree on which cryptographic algorithms to use.
- Message authentication codes (MACs): Detect whether messages were altered in transit.
In 1999, the Internet Engineering Task Force (IETF) took over and renamed the protocol Transport Layer Security (TLS), starting with TLS 1.0. From that point, TLS became an open standard that continued to evolve:
- TLS 1.0 (1999): IETF takeover and renaming from SSL
- TLS 1.1 (2006): Better error handling, improved cipher negotiation
- TLS 1.2 (2008): Stronger encryption and authentication
- TLS 1.3 (2018): Simplified handshake, faster setup, deprecated old algorithms
Today, TLS 1.3 is the modern standard, and all older SSL/TLS versions are considered insecure and deprecated.
Certificates and the Chain of Trust
TLS prevents MITM attacks using something called a digital certificate. A certificate is like a digital ID card issued to a website or server by a trusted authority.
Note: you can run the following command in a Linux, macOS, or WSL terminal to view a real, live certificate from https://example.com. You can see how the fields I show in the example certificate images line up with a real certificate.
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \ openssl x509 -noout -text
Each certificate includes:
- The domain name it’s issued for (example.com)
- The server’s public key
- The certificate authority (CA) that signed it
- The expiration date
- A digital signature from the CA
The format of these certificates follows the X.509 standard. When a client (e.g. a browser) connects to a server, it asks the server for its digital certificate. The client uses this certificate to verify its authenticity (i.e. the server is really who they say they are) using some cryptographic techniques, and it is used in the TLS handshake process that we’ll cover later.
Certificate Authorities (CAs)
CAs are trusted third parties (organizations like Let’s Encrypt, DigiCert, or GlobalSign) that verify the identity of the certificate holder. Your browser or operating system maintains a list of root certificates (known as a “trust store”) that it automatically trusts. When you connect to a website, your browser checks whether the server’s certificate was issued (directly or indirectly) by one of those trusted authorities.
This process to verify the certificate’s authenticity involves a chain of trust. This might be verifying the root certificate (in the browser or OS’s trust store) against the server’s certificate, or it might involve verifying an intermediate certificate (signed by a separate CA) which can then be used to verify the server’s certificate.
In most cases, verifying a server’s certificate involves a 2 or 3-step process, depending on if the server’s certificate was signed directly by a root CA or an intermediate CA.
- Root CA → Server Certificate
- Root CA → Intermediate CA → Server Certificate
If the server’s certificate was signed by an intermediate CA, and that CA was signed by a trusted root, the browser knows the chain is legitimate.
Digital Signature
A digital signature is a cryptographic method used to verify that a message or file truly came from a specific sender and hasn’t been altered in transit. It works by combining hashing and asymmetric encryption: first, the sender runs the original message through a hash function (like SHA-256) to produce a short, unique fingerprint of the data. That hash is then encrypted with the sender’s private key, creating the digital signature. Anyone with the sender’s public key can decrypt the signature to retrieve the hash and compare it to a newly computed hash of the received message. If the two match, it proves that the message is authentic (it really came from the holder of the private key) and that its contents haven’t been modified since it was signed.
How TLS Certificates Are Created
Before a server can offer a TLS connection, it needs a certificate.
Here’s the simplified process:
- Generate key pair: The server creates a public and private key.
- Create a Certificate Signing Request (CSR): This request includes the domain name and public key. It’s signed with the server’s private key. A CSR is often a simple file containing plaintext information about the server and a digital signature.
- Verification: The CA verifies domain ownership (for example, by checking a special DNS record or file on the server).
- Issuance: The CA signs the certificate using its private key and sends it back to the server.
- Installation: The server installs the certificate and sends it to clients when requested during the TLS handshake process.
Most certificates expire every few months or a year, which is why admins use automated tools (like Certbot or built-in scripts) to renew them before they expire.
The TLS Handshake Explained
Now that we understand trust and encryption, let’s see how TLS actually establishes a secure connection. Every TLS session starts with a handshake, a short negotiation where the client and server agree on encryption parameters and verify each other’s identity.
Note that we will look at the handshake for TLS 1.2 for simplicity and then discuss the changes offered by 1.3 later.
Step 1: TCP Setup
TLS runs on top of TCP. Before anything else, the client and server complete the standard three-way TCP handshake:
- Client → SYN
- Server → SYN-ACK
- Client → ACK
Now they’re ready to start the TLS handshake using asymmetric encryption.
Step 2: ClientHello
The client sends a ClientHello message containing:
- Supported TLS versions
- Supported cipher suites
- A random number (used in key generation)
- Optional session ID (for resuming connections)
Step 3: ServerHello
The server responds with a ServerHello, which includes:
- The chosen TLS version and cipher suite
- Another random number
- The server’s digital certificate
Step 4: Certificate Verification
To verify the certificate’s authenticity, the client hashes (e.g. with SHA-256) the certificate contents (minus the digital signature) to obtain some value. It then decrypts the digital signature (remember, this was encrypted with the server’s private key) using the server’s public key to obtain some value. If the two values match, then the client can rest assured that the certificate was created by the server in question.
The client can perform several other checks to ensure that the server can be trusted:
- Does the domain name match?
- Is it expired or revoked (by e.g. checking an up-to-date certificate revocation list)
- Is it allowed for TLS authentication?
If everything passes, the client trusts that the server is legitimate.
Key Exchange and Session Keys
Once trust is established, the client and server need to agree on a symmetric key for encrypting data.
In TLS 1.2:
- The client generates a random pre-master secret (a temporary, shared numerical value used for computing a later symmetric key).
- It encrypts this with the server’s public RSA key and sends it.
- The server decrypts it using its private key to arrive at the same pre-master secret.
- Both sides use the pre-master secret and random numbers to derive the final session keys.
- The client encrypts a finished message and sends it to the server. The server decrypts it using the newly derived session key and verifies that the message contains the expected “finished” value.
- The server repeats the process: it encrypts a “finished” message using the session key and sends it to the client.
If both client and server successfully received and decrypted the “finished” messages, then they know the symmetric keys were successfully computed. These session keys are then used for symmetric encryption (e.g., AES) for the rest of the session.
Ending a TLS Session
When either side is done communicating, they send a Close Notify message to end the secure session gracefully. The underlying TCP connection is then closed with the usual four-way FIN/ACK handshake.
TLS 1.3 Changes
TLS 1.3 simplifies and strengthens the protocol by removing outdated or insecure algorithms (like RSA key exchange) and using faster, more secure methods, such as Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE), for key exchange. It also reduces the handshake from two round trips to one, improving connection speed while enhancing forward secrecy and overall cryptographic security.
Let’s take a look at two of the most prominent TLS 1.3 updates.
ECDHE Key Exchange
TLS 1.3 improves on this with the Elliptic-curve Diffie-Hellman Ephemeral (ECDHE) protocol:
- Both sides generate temporary (ephemeral) public/private key pairs.
- They exchange public keys in the Hello messages.
- Each computes a shared secret using its private key and the other’s public key.
- This shared secret becomes the basis for the session key.
This approach is faster, as it allows the server to completely compute the session key using the server’s ECDHE private key, the client’s ECDHA public key, and both client and server randomly generated values. As a result, the server can immediately send an encrypted “finished” message along with its own certificate earlier in the handshake process.
The client can then generate the same session key (after verifying the server’s certificate) using the shared randoms, its own ECDHE private key, and the server’s ECDHE public key. This saves a server-to-client message, thus saving time during the handshake process.
This process also offers perfect forward secrecy (PFS), meaning even if someone steals the server’s private key later, they can’t decrypt past sessions.
Resumption
In TLS 1.3, session resumption allows a client and server that have previously communicated to re-establish a secure connection much faster, without performing a full handshake again.
After the first successful handshake, the server sends the client a session ticket, which contains encrypted information about the previous session (specifically, the cryptographic parameters needed to derive the same symmetric keys). When the client reconnects later, it includes this ticket in its ClientHello message. The server decrypts the ticket, verifies that it’s still valid, and uses it to regenerate the shared secret, skipping the expensive key exchange and certificate validation steps. This “abbreviated handshake” typically requires just one round trip instead of two, significantly reducing latency.
TLS 1.3 also introduces an optional 0-RTT (Zero Round Trip Time) mode, where the client can send data immediately on reconnect using previously established keys. However, this comes with a small replay-attack trade-off, so it’s usually reserved for low-risk data.
Authenticating Both Sides (Mutual TLS)
Usually, TLS only authenticates the server (e.g. you verify that you’re talking to the real example.com). But some systems, like corporate networks or IoT fleets, also require the client to prove its identity. This is called mutual TLS (mTLS).
In mTLS, the handshake includes an extra step where the server requests the client’s certificate. Both sides then verify each other’s certificates using the same chain-of-trust process before establishing an encrypted channel.
TLS in Everyday Life
Even if you’ve never configured a certificate yourself, TLS is working constantly in the background:
- Browsers use it for HTTPS websites.
- Email clients use it for SMTP, IMAP, and POP3.
- IoT devices rely on it for secure MQTT (MQTTS) or HTTPS APIs.
- Software updates, code repositories, and payment gateways all depend on it.
Without TLS, the modern internet (and connected devices) would simply not be trustworthy. It provides more than just encryption, as it helps ensure the CIA Triad model for information security:
- Confidentiality: Your data stays private.
- Integrity: It can’t be modified without detection.
- Authentication: You know who you’re talking to.
The next time your embedded device connects to an API endpoint or cloud dashboard, remember the layers of cryptography working behind the scenes to make that connection secure.
If you would like to see how TLS integrates into IoT device firmware, check out my IoT Firmware Development with ESP32 and ESP-IDF course. In the course, we cover the basics of ESP-IDF, reading from sensors, connecting to the internet via WiFi, posting data via HTTP REST calls, securing connections with TLS, and interacting with MQTT brokers.
