Skip to content
networking encryption

SSL/TLS (TLS)

tls ssl encryption https certificates
Plain English

TLS (the modern version of SSL) is the technology that puts the padlock icon in your browser’s address bar. It encrypts the data traveling between your device and a website so that nobody in between (your ISP, a hacker on the same Wi-Fi, a government) can read or tamper with it. Every time you see “https://” instead of “http://”, TLS is working.

Technical Definition

Transport Layer Security (TLS) is a cryptographic protocol that provides confidentiality, integrity, and authentication for data in transit. TLS 1.3 (RFC 8446) is the current standard; SSL and TLS 1.0/1.1 are deprecated due to known vulnerabilities (POODLE, BEAST, CRIME).

TLS 1.3 handshake (1-RTT):

  1. ClientHello: client sends supported cipher suites, key share (ECDHE public key), and TLS version
  2. ServerHello + Certificate: server selects cipher, sends its key share, certificate chain, and encrypted extensions
  3. Finished: both sides derive session keys from the shared secret; application data can begin

TLS 1.3 improvements over 1.2:

  • Removed insecure ciphers (RC4, DES, static RSA key exchange)
  • Mandatory forward secrecy via ephemeral Diffie-Hellman (ECDHE)
  • 1-RTT handshake (down from 2-RTT in TLS 1.2)
  • 0-RTT resumption for repeat connections (with replay protection caveats)

Certificate chain verification:

  1. Server presents its leaf certificate + intermediate CA certificate(s)
  2. Client validates the chain up to a trusted root CA in its trust store
  3. Client checks certificate validity dates, revocation status (OCSP/CRL), and Subject Alternative Names (SANs) match the requested hostname

Common cipher suite example: TLS_AES_256_GCM_SHA384 (AES-256 for encryption, GCM mode for authenticated encryption, SHA-384 for key derivation).

BrowserServer1. ClientHelloSupported ciphers, TLS version2. ServerHello + CertificateChosen cipher, public key3. Key ExchangePre-master secret (encrypted)4. FinishedSession keys derivedEncrypted application data (AES-256-GCM)TLS 1.3 completes handshake in 1 round trip (1-RTT)

TLS certificate inspection

# Check TLS certificate of a site
$ openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R3
notBefore=Mar 15 00:00:00 2026 GMT
notAfter=Jun 13 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

# Test TLS version and cipher
$ openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | grep -E "Protocol|Cipher"
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

# Generate a self-signed certificate (testing only)
$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
  -sha256 -days 365 -nodes -subj "/CN=localhost"
In the Wild

TLS secures virtually all internet traffic. Let’s Encrypt made free, automated TLS certificates the standard; there is no reason for any production site to run without HTTPS in 2026. Beyond web browsers, TLS secures email (SMTP with STARTTLS), database connections (PostgreSQL, MySQL), API calls, and VPN tunnels. Certificate expiration is one of the most common causes of production outages; monitoring tools like Certbot auto-renewal, AWS Certificate Manager, and cert-manager (Kubernetes) automate rotation. In enterprise environments, TLS inspection (decryption at the firewall for DPI, then re-encryption) is standard practice for visibility into encrypted traffic, though it requires careful key management and privacy considerations.