TLS / HTTPS

HTTPS is just HTTP inside an encrypted TLS tunnel. Here is how that tunnel is built and what it guarantees.

Plain HTTP travels in the clear — anyone between you and the server can read or change it. TLS (Transport Layer Security, the successor to SSL) wraps the connection so that it is private, tamper-evident, and authenticated. HTTP over TLS is what we call HTTPS.

What TLS gives you

• Confidentiality — the data is encrypted, so eavesdroppers see only noise.
• Integrity — if someone flips a bit in transit, it is detected.
• Authentication — a certificate proves you are really talking to the site you think you are.

The handshake

After TCP connects, TLS negotiates the secure channel:

1. The client says hello and lists the cipher suites and TLS versions it supports.
2. The server picks one and sends its certificate.
3. They perform a key exchange (modern TLS uses ephemeral Diffie–Hellman) to agree on a shared secret that no eavesdropper can derive.
4. Both switch to symmetric encryption using that secret, and the real HTTP begins.

TLS 1.3 streamlined this to a single round trip, and can even resume a previous session with zero round trips.

Certificates and trust

A certificate binds a public key to a domain name, and is signed by a Certificate Authority (CA) that your browser already trusts. The chain looks like: your browser trusts a root CA → the root signs an intermediate → the intermediate signs the site’s certificate. If any link is broken or expired, you get a warning.

Getting a certificate

These days certificates are free and automatic. Tools like Let’s Encrypt issue them after proving you control the domain, and servers like Caddy renew them on their own. You rarely touch a .pem file by hand anymore.