Networking

HTTPS & TLS

HTTPS is just HTTP run over TCP with one thing added: TLS, a layer that turns a plaintext connection anyone on the path could read or tamper with into one that's private, tamper-evident, and provably talking to the right server.

Quick reference

What it is: A layer beneath HTTP (and other protocols) providing encryption, integrity, and server authentication over TCP.
Mental model: A sealed, tamper-evident envelope with a wax seal you can verify — not just an opaque envelope.
Key numbers: Port 443 by default; TLS 1.3 needs 1 round trip to establish a session, TLS 1.2 needs 2.
Reach for it when: Any time data crosses a network you don't fully control — which, for an internet-connected device, is always.

Why plain HTTP isn't safe

A plain HTTP request travels across every network link between client and server exactly as typed — readable and editable by anything in between: a shared Wi-Fi network, an ISP, a compromised router. There's no cryptography involved at all, so there's nothing stopping any of them from reading credentials in transit or quietly rewriting the response.

What TLS actually guarantees

Confidentiality: Encryption — anyone intercepting the traffic sees ciphertext, not the actual content.
Integrity: Any tampering with the data in transit is detectable — the connection fails rather than silently delivering altered data.
Authentication: The client can cryptographically verify the server is who it claims to be, via its certificate — not just "someone answered on that IP address."

The handshake

Before any application data flows, client and server negotiate a shared secret and verify identity:

TLS 1.3 (shown here) does this in one round trip; TLS 1.2 needs an extra round trip and separates several of these steps.

Why TLS mixes two kinds of cryptography

TLS uses asymmetric cryptography (like RSA or elliptic-curve Diffie-Hellman) only during the handshake, to safely agree on a secret over an untrusted channel without ever transmitting that secret directly. Once both sides share that secret, they switch to symmetric cryptography (like AES or ChaCha20) for the actual data — because symmetric encryption is dramatically faster. This hybrid approach gets the security property only asymmetric crypto provides (secure agreement without a pre-shared secret) and the performance only symmetric crypto provides, without picking one over the other.

Certificates and the chain of trust

A certificate binds a public key to an identity (a domain name), signed by a Certificate Authority (CA) that vouches for that binding. Trust is established through a chain:

The server presents its own ("leaf") certificate.
That certificate is signed by an intermediate CA's certificate.
The intermediate is signed by a root CA — one of a small set pre-installed and trusted by the client's OS/browser.

If every signature in that chain checks out, and the certificate's name matches the server being connected to, and it hasn't expired, the client trusts the connection. Break any one link — wrong hostname, expired certificate, a self-signed certificate with no trusted signer — and the client should refuse to proceed.

"SSL" vs. "TLS" — same lineage, different name

"SSL" and "TLS" are often used interchangeably, and that's close enough for casual conversation — but they're not simply two names for the same thing running today. SSL (Secure Sockets Layer) came first; TLS (Transport Layer Security) is its direct successor, renamed when the protocol passed from Netscape to the IETF standards body. Every version of SSL (up to SSL 3.0) is now considered broken and disabled everywhere — actual, non-deprecated traffic today runs on TLS 1.2 or TLS 1.3, never SSL. The name "SSL" survives mostly as a habit — "SSL certificate," "SSL termination" (see Proxy for what actually terminates it) — describing what is, in every modern system, actually TLS underneath.

Mutual TLS

Standard TLS only authenticates the server to the client. Mutual TLS (mTLS) adds a client certificate too, so the server can cryptographically verify which client is connecting — common wherever both ends need to trust each other's identity, most notably device-to-cloud connections in IoT fleets, where a unique per-device certificate is often how the backend distinguishes one device from another at the transport layer, not just at the application layer.

TLS on constrained devices

Full TLS libraries (OpenSSL) are too large for many microcontrollers; embedded-focused libraries like mbedTLS and wolfSSL trade some flexibility for a much smaller memory and code footprint, deliberately built to run the same handshake and record-layer logic within a few tens of KB of RAM. CoAP has its own matching lightweight variant, DTLS (Datagram TLS) — TLS's guarantees adapted to run over unreliable, unordered UDP instead of TCP.

Real-world applications

Every HTTPS website — the padlock icon in a browser is exactly the handshake and certificate chain above having succeeded.
IoT device-to-cloud connections — AWS IoT Core, Azure IoT Hub, and similar platforms use mTLS with a unique per-device certificate as the standard way to authenticate a fleet of devices.
Secure OTA firmware updates — TLS protects a firmware image in transit; the device separately verifies the image's own signature (a chain of trust distinct from, but often paired with, the connection's TLS certificate).
MQTT over TLS — production MQTT deployments almost always run on port 8883 (MQTT over TLS) rather than plaintext 1883.

Gotchas

Field notes

Certificate expiration is a genuinely common cause of fleet-wide IoT outages — a certificate that quietly expires can take an entire device fleet offline simultaneously, with no code change involved at all.
TLS certificate validation depends on the device's own clock being roughly correct — a device with a dead RTC or no time sync can reject perfectly valid certificates as "not yet valid" or "expired," a confusing failure mode that has nothing to do with the certificate itself.
A "connection reset" during the handshake on a constrained device is very often simply running out of RAM mid-handshake, not a network or certificate problem — TLS's memory footprint is a real design constraint, not just a performance one, on small MCUs.
Self-signed certificates and disabled certificate validation are common shortcuts during development that quietly defeat the entire point of TLS if they ever ship to production.