SSL/TLS

SSL/TLS is the security layer that sits between your application and the raw network connection. When your browser talks to a website over HTTPS, TLS wraps the HTTP traffic so that anyone watching the wire (your ISP, a coffee shop router, a compromised switch) sees only scrambled bytes instead of your passwords, cookies, and credit card numbers.

SSL was the original protocol, created by Netscape in the mid 1990s. SSL 2.0 and 3.0 are both broken and disabled everywhere. The protocol was renamed TLS in 1999, and the versions that matter today are TLS 1.2 (2008) and TLS 1.3 (2018). People still say SSL out of habit, but every real deployment is running TLS.

TLS gives you three guarantees at once. Confidentiality means the data is encrypted. Integrity means tampering is detected, because each message carries an authentication tag. Authentication means the server proves who it is using a certificate signed by a trusted Certificate Authority, so you know you are really talking to your bank and not an impostor.

Before any application data flows, the client and server run a handshake. The client sends a ClientHello listing the TLS versions and cipher suites it supports plus a random number. The server replies with its choice of cipher, its own random number, and its certificate chain.

The client verifies the certificate against the CA trust store built into the operating system or browser. It checks the signature, the expiry date, and that the hostname matches. If anything is wrong you get the familiar red warning page. Both sides then run a key exchange, almost always Elliptic Curve Diffie-Hellman, to agree on a shared secret without ever sending that secret over the network.

From the shared secret they derive symmetric session keys, typically for AES-GCM or ChaCha20-Poly1305. Asymmetric crypto is slow, so it is used only to bootstrap the handshake; the bulk traffic is encrypted with fast symmetric keys. TLS 1.2 needs two network round trips for this. TLS 1.3 trimmed the handshake to a single round trip, and with session resumption it supports 0-RTT, where the client can send data in its very first message.

The honest answer is to use TLS for everything. Browsers mark plain HTTP pages as Not Secure, search engines rank HTTPS higher, and free certificates from Let's Encrypt removed the cost excuse years ago. Internal service-to-service traffic should use TLS too, often through mutual TLS where both sides present certificates.

The trade-off used to be CPU cost and latency, but modern hardware has AES instructions built in and TLS 1.3 cut the round trips, so the overhead is now small for most workloads. The real cost is operational: certificates expire, usually every 90 days with Let's Encrypt, and an expired cert takes the whole site down. Automating renewal with tools like certbot or your cloud load balancer is essential.

A common pattern is TLS termination at the edge. A load balancer or CDN decrypts incoming TLS, inspects and routes the request, then forwards it to backends over the internal network. This centralizes certificate management but means traffic inside your network may be plaintext unless you re-encrypt it.

Type https://github.com into your browser. Your machine opens a TCP connection to GitHub on port 443, then starts a TLS handshake. GitHub presents a certificate signed by a CA such as DigiCert or Sectigo. Your browser confirms the chain leads to a root it trusts and that the name on the certificate is github.com.

The two sides agree on AES-256-GCM and derive session keys. Only now does your actual HTTP request, including your login cookie, travel across the internet, fully encrypted. Anyone capturing the packets sees the destination IP and that it is TLS traffic, but not the URL path, the headers, or the body.

You can inspect all of this yourself. Run openssl s_client -connect github.com:443 to see the certificate chain and negotiated cipher, or click the padlock in your browser to view the certificate details, issuer, and expiry date.