What TLS Does and Why It Matters

Transport Layer Security is the cryptographic protocol that protects the majority of internet traffic. Every time you log into a website, submit a form, make a payment, or use an API — if you see “https://” in the URL, TLS is doing the work.

It provides three guarantees:

Confidentiality: traffic between client and server is encrypted. An attacker who intercepts the packets sees ciphertext, not content.

Integrity: any modification to the data in transit is detectable. If a byte is changed, the record authentication tag fails and the connection is terminated.

Authentication: the server proves it holds the private key corresponding to a certificate issued for that domain. The client knows it’s talking to the real server, not an impersonator.

Without TLS, every unencrypted HTTP connection is visible to anyone on the same network — public Wi-Fi, ISPs, corporate network operators. With TLS, only the endpoints can read the content.

TLS 1.3 vs TLS 1.2: What Changed

TLS 1.3, published as RFC 8446 in 2018, was the first major version change in over a decade. The design goals were to make the protocol faster, simpler, and more secure by removing a decade’s worth of legacy decisions.

Key Differences: TLS 1.2 vs TLS 1.3

  Feature                    | TLS 1.2          | TLS 1.3
  ─────────────────────────────────────────────────────────
  Handshake round trips      | 2 RTT            | 1 RTT (0-RTT resumption)
  RSA key exchange           | Supported        | Removed
  Forward secrecy            | Optional (ECDHE) | Mandatory
  Deprecated cipher suites   | Still selectable | Removed entirely
  Compression                | Supported        | Removed (CRIME attack)
  Renegotiation              | Supported        | Removed
  Session tickets (security) | Complex          | Redesigned
  Available cipher suites    | 37+              | 5 curated suites

The removal of RSA key exchange is the most significant change. In TLS 1.2 with RSA, the session key was encrypted with the server’s RSA public key and sent to the server. If the server’s private key was ever compromised (even years later), an attacker who had recorded past sessions could decrypt them all. This is the “harvest now, decrypt later” attack.

TLS 1.3 requires ephemeral Diffie-Hellman key exchange (ECDHE) for every session. Session keys are derived from temporary values that are discarded after the session ends. Compromise of the server’s long-term private key cannot decrypt past sessions. This property is called forward secrecy.

The TLS 1.3 Handshake in Detail

TLS 1.3 completes the handshake in a single round trip (1-RTT), compared to TLS 1.2’s two round trips.

TLS 1.3 Handshake

  Client                                          Server
    |                                                 |
    |──── ClientHello ────────────────────────────>   |
    |      - TLS 1.3 version                          |
    |      - Supported cipher suites                  |
    |      - Client's key share (ECDH public value)   |
    |      - Random bytes                             |
    |                                                 |
    |   <──── ServerHello ────────────────────────────|
    |          - Chosen cipher suite                  |
    |          - Server's key share (ECDH public val) |
    |          - Random bytes                         |
    |          - Certificate (encrypted)              |
    |          - CertificateVerify (signature)        |
    |          - Finished (MAC over handshake)        |
    |                                                 |
    | [Client derives same session key from           |
    |  both key shares — without transmitting         |
    |  the key itself]                                |
    |                                                 |
    |──── Finished ───────────────────────────────>   |
    |                                                 |
    |======= Encrypted Application Data =============|

The key exchange uses Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE). Each party generates a temporary key pair. They exchange public values. Each derives the same shared secret from the other’s public value and their own private value. The private values are discarded. Neither party ever transmits the session key.

Note that the certificate and most of the server’s response are encrypted in TLS 1.3, even during the handshake. This is a significant privacy improvement over TLS 1.2, where the certificate was sent in plaintext, allowing passive observers to see which server the client was connecting to (beyond just the IP address and SNI).

0-RTT Session Resumption

TLS 1.3 supports a mode where clients resuming a recent session can send application data in their very first message, before the handshake completes. This is called 0-RTT (zero round-trip time).

0-RTT data arrives before the server can verify the client’s identity in that exchange, which creates a specific risk: replay attacks. An attacker who captures a 0-RTT request can re-send it, potentially triggering the same action (like a payment) multiple times.

This makes 0-RTT inappropriate for non-idempotent requests. Many implementations restrict 0-RTT to safe HTTP methods (GET, HEAD) and exclude it from POST, PUT, or DELETE. RFC 8470 documents the “Early-Data” header for servers to signal they received and processed 0-RTT data, allowing clients to detect replays.

For most applications, using 0-RTT requires careful analysis. Disabling it is safer for anything involving state changes.

TLS Cipher Suites

A cipher suite specifies the combination of algorithms used in a TLS connection. TLS 1.3 defines only five:

TLS 1.3 Cipher Suites

  TLS_AES_256_GCM_SHA384
  TLS_AES_128_GCM_SHA256         (recommended minimum)
  TLS_CHACHA20_POLY1305_SHA256   (preferred on hardware without AES acceleration)
  TLS_AES_128_CCM_SHA256
  TLS_AES_128_CCM_8_SHA256       (short tag, for constrained environments)

The cipher suite name encodes three things:

• The bulk encryption algorithm (AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305)
• The hash function used in the HKDF key derivation (SHA-384, SHA-256)
• All TLS 1.3 suites use ECDHE for key exchange — it’s not encoded because there’s no option

In TLS 1.2, cipher suites also encode the key exchange algorithm and signature algorithm, which is why TLS 1.2 suite names look like: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

Certificates in TLS

Certificates are the mechanism for authenticating the server. A certificate binds a public key to an identity (like a domain name) and is signed by a Certificate Authority (CA) that both parties trust.

Certificate structure (X.509):

X.509 Certificate Fields

  Version:              3
  Serial Number:        2A:B4:C1:... (unique per CA)
  Signature Algorithm:  SHA256WithRSAEncryption or ecdsa-with-SHA256
  Issuer:               CN=DigiCert TLS CA, O=DigiCert Inc
  Validity:
    Not Before:         2025-01-01
    Not After:          2025-12-31
  Subject:              CN=yourdomain.com
  Subject Public Key:   EC (prime256v1) / RSA 2048-bit
  Subject Alt Names:    yourdomain.com, www.yourdomain.com
  Key Usage:            Digital Signature, Key Encipherment
  Basic Constraints:    CA: FALSE
  CRL Distribution:     http://crl3.digicert.com/...
  OCSP:                 http://ocsp.digicert.com
  CT Precertificate:    [embedded SCTs]

ECDSA vs RSA certificates: RSA certificates (2048 or 4096-bit keys) are widely supported. ECDSA certificates (P-256 or P-384 curves) are smaller, faster to verify, and equally secure. Modern servers can run dual-certificate configurations — serving ECDSA to clients that support it and RSA to older clients.

Certificate Transparency

Certificate Transparency (CT) is an auditing framework where all publicly trusted CAs must log every certificate they issue to public, append-only logs. Browsers (Chrome since 2018, Safari and Firefox following) require CT compliance — without embedded Signed Certificate Timestamps (SCTs), a certificate is rejected.

This means you can search public CT logs to find every certificate ever issued for a domain. Tools like crt.sh provide a searchable interface:

# Check what certificates exist for your domain
curl "https://crt.sh/?q=yourdomain.com&output=json" | jq '.[].name_value' | sort -u

This is useful for discovering certificates issued without your knowledge — a sign of potential account compromise or a domain you forgot to protect.

TLS in Practice: Configuration Examples

Nginx (TLS 1.2 + 1.3):

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;   # let TLS 1.3 use client preference
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
}

Testing TLS configuration:

# Verify what TLS version and cipher suite was negotiated
openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep -E "Protocol|Cipher"

# Check if HSTS is set
curl -sI https://yourdomain.com | grep -i strict

# Full certificate chain check
openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text

Common TLS Vulnerabilities and Mitigations

Most of these are eliminated by using TLS 1.3 with a modern OpenSSL version. The vulnerabilities are listed here because they appear in compliance scan reports against older systems that haven’t been patched or reconfigured.

What Post-Quantum TLS Looks Like

NIST finalized post-quantum cryptography standards in 2024, and browser vendors are beginning to integrate them. ML-KEM (Kyber) is being added to TLS key exchange alongside ECDHE — initially as a “hybrid” mode where both algorithms must be secure for the connection to be secure.

Chrome began deploying hybrid ECDHE + Kyber (X25519MLKEM768) in 2024. This protects against future quantum computers that could break elliptic curve key exchange, without breaking compatibility with existing certificate infrastructure.

For most organizations, the immediate action is to ensure you’re using TLS 1.3 (which supports the hybrid key exchange) and monitoring the IETF and NIST standards as post-quantum TLS is formalized in the coming years.

TLS is not static. It has been continuously improved to address newly discovered attacks while maintaining backward compatibility where possible and breaking it where necessary. The current deployment — TLS 1.3 with ECDHE and ECDSA certificates — represents the best of what’s been learned from 30 years of iterating on encrypted network communication.