Encryption, TLS, and Cryptography Deep Dive

#The Big Picture: Four Primitives

Rule of thumbAsymmetric is used to establish a shared secret, then symmetric takes over for bulk data. This is TLS in a nutshell.

#AES (Advanced Encryption Standard)

WhatBlock cipher operating on 128-bit blocks. Key sizes: 128, 192, or 256 bits.

Why AESSelected by NIST in 2001 after open competition. Hardware acceleration (AES-NI instruction) makes it extremely fast on modern CPUs. Considered quantum-resistant for 256-bit keys (would need 2^128 operations with Grover's algorithm).

WhereEverywhere — TLS, disk encryption (FileVault, BitLocker, LUKS), VPNs, WiFi (WPA2/WPA3), SSH, cloud KMS.

#AES Modes of Operation

AES-GCM deep dive

• Combines CTR mode (encryption) with GHASH (authentication tag)
• Produces: ciphertext + 128-bit authentication tag
• Decryption MUST verify tag before decrypting (otherwise oracle attacks)
• Critical weakness: nonce reuse → catastrophic (reveals authentication key AND plaintext XOR)
• Used in: TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384, TLS 1.3 AES_256_GCM_SHA384

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = os.urandom(32)        # 256-bit key
nonce = os.urandom(12)      # 96-bit nonce (never reuse with same key!)
data = b"secret message"
aad = b"authenticated but not encrypted"

aesgcm = AESGCM(key)
ciphertext = aesgcm.encrypt(nonce, data, aad)   # ciphertext + 16-byte tag
plaintext = aesgcm.decrypt(nonce, ciphertext, aad)

Advantages

• AEAD: encryption and authentication in one pass
• Hardware-accelerated (PCLMULQDQ + AES-NI)
• Widely supported and well-studied

Disadvantages

• Nonce misuse is fatal (unlike AES-SIV)
• Nonce is 96 bits — if randomly generated, risk of collision after ~2^48 messages with same key (birthday bound)
• Side-channel vulnerable in software without constant-time implementation

#ChaCha20-Poly1305

WhatStream cipher (ChaCha20) + MAC (Poly1305). AEAD.

Why ChaCha20Designed by D.J. Bernstein as an alternative to AES for systems without hardware AES acceleration (e.g., older ARM chips). Resistant to timing side-channels in software because it uses only XOR, addition, rotation.

WhereTLS 1.3 (TLS_CHACHA20_POLY1305_SHA256), WireGuard VPN, Signal Protocol, OpenSSH (chacha20-poly1305@openssh.com).

Advantages

• Software performance on mobile/IoT
• Inherently constant-time

Disadvantages

• No hardware acceleration (slower on AES-NI chips)
• Less deployment history than AES

#RSA

WhatAsymmetric encryption based on integer factoring hardness. Key sizes: 2048, 3072, 4096 bits.

Why RSAFirst practical public-key system (1977). Used for key exchange (RSA key transport in TLS 1.2) and digital signatures.

WhereTLS certificates (signing), S/MIME, PGP, SSH host keys (legacy), JWT (RS256).

How it works (simplified):

Key generation:
  p, q = large primes
  n = p × q              (public modulus)
  e = 65537              (public exponent, standard)
  d = e^-1 mod φ(n)      (private exponent)

Encryption:   c = m^e mod n
Decryption:   m = c^d mod n
Signature:    sig = hash(m)^d mod n
Verification: hash(m) = sig^e mod n

RSA vs ECC key strength comparison

Advantages

• Well-understood, widely deployed
• Simple conceptually
• Large ecosystem of implementations

Disadvantages

• Large key and signature sizes (vs ECDSA)
• Slow operations vs ECC
• Quantum-vulnerable (Shor's algorithm breaks RSA)
• Vulnerable to timing attacks without blinding
• PKCS#1 v1.5 padding attacks (Bleichenbacher); use OAEP/PSS

Padding schemes

#Elliptic Curve Cryptography (ECC)

WhatAsymmetric cryptography using elliptic curves over finite fields. Smaller keys for equivalent security.

Why ECCSmaller keys = faster operations, less bandwidth, better for constrained devices. Also no known sub-exponential attacks (unlike RSA factoring).

WhereTLS (ECDHE, ECDSA), Bitcoin/Ethereum (secp256k1), SSH (ed25519), Signal (Curve25519), TLS certificates (ECDSA), JWT (ES256).

#Common Curves

ECDH (key exchange)

Alice: ephemeral private key a, public key A = a·G
Bob:   ephemeral private key b, public key B = b·G
Shared secret: S = a·B = b·A = ab·G

ECDSA (signing)

• Requires a random k per signature
• Critical: reusing k with same private key reveals the private key (PlayStation 3 attack, Bitcoin key extractions)
• EdDSA (ed25519) uses deterministic k → immune to this

Advantages

• Smaller keys and signatures than RSA
• Faster operations
• Ed25519: deterministic, constant-time, immune to k-reuse

Disadvantages

• More complex to implement correctly (side-channel risks)
• Quantum-vulnerable (Shor's algorithm breaks ECDLP too)
• Curve choice matters (NIST curves have some controversy)

#Diffie-Hellman Key Exchange (DH / ECDH)

WhatTwo parties derive a shared secret over an untrusted channel without transmitting the secret.

WhyFoundation of forward secrecy. Neither party needs to encrypt the key — it's derived from ephemeral values.

Classic DH (finite field):
  Public: prime p, generator g
  Alice: secret a → A = g^a mod p → sends A to Bob
  Bob:   secret b → B = g^b mod p → sends B to Alice
  Alice: S = B^a mod p = g^ab mod p
  Bob:   S = A^b mod p = g^ab mod p
  Both have S, attacker only saw A, B, g, p

ECDH uses the same concept over elliptic curves (much smaller key for same security).

Forward SecrecyUse ephemeral DH (DHE or ECDHE) — generate new keypair per session. If long-term private key is compromised later, past sessions cannot be decrypted because ephemeral keys are discarded.

#Hashing Algorithms

Where each is used

• SHA-256: TLS signatures, certificates, Bitcoin PoW, Git commit IDs, HMAC-SHA256
• SHA-512: HMAC in SSH (hmac-sha2-512), high-security signatures
• SHA-3: Available in TLS 1.3, government applications requiring post-SHA-2 algorithm
• BLAKE3: Fast checksums, general-purpose (Cargo, Zig, Cloudflare)
• Argon2id: Password hashing (OWASP recommendation), key derivation
• bcrypt: Legacy password hashing (web apps) — work factor 10-12 typical

#TLS in Depth

Last verified2026-10

What is this?TLS (Transport Layer Security, the successor to SSL) is the protocol that puts the "S" in HTTPS, SMTPS, IMAPS, LDAPS and most service-to-service traffic. It sits between TCP (or QUIC) and the application, and turns an untrusted network path into a private, tamper-evident channel to a server whose identity has been checked. The sections below go from first principles to byte-level detail: the cryptography it uses, certificates and PKI, cipher suites, the record layer, both handshakes, the defenses built around TLS, the attacks that shaped it, and the TLS 1.3 key schedule.

Why it mattersAlmost every security question about the web eventually lands on TLS: "how do you know you're talking to the real bank?", "what does a MITM proxy actually do?", "why did we disable TLS 1.0?", "why can't the SOC see inside this traffic anymore?". Interviewers use TLS to probe whether you understand cryptography as a system: which primitive does which job, and what fails when one is missing.

The primitives themselves (AES, ChaCha20, RSA, ECC, Diffie–Hellman, hashing, HMAC, HKDF) are covered earlier on this page. This part is about how TLS assembles them.

#TLS Fundamentals: Goals, Players and Versions

#What TLS protects

Warning

TLS does not give non-repudiationBoth sides hold the same symmetric session keys, so either side could have produced any given record. A packet capture of a TLS session can't prove to a third party that the server sent a particular message. That needs an application-level signature (e.g. signed JWTs, S/MIME, document signing). Interviewers like this trap.

#The players

#Versions

Memory hook

"TLS 1.0 is SSL 3.1"The wire version for TLS 1.0 is 3,1 (0x0301), TLS 1.2 is 3,3, TLS 1.3 is 3,4. The rename from SSL to TLS was mostly political (Netscape → IETF), not a redesign. That's why "SSL certificate" and "SSL offload" are still everyday terms, even though no one should be running SSL.

#How TLS Uses Cryptography

TLS is a hybrid system. Asymmetric cryptography is slow but solves the "how do two strangers agree on a secret and know who they're talking to" problem. Symmetric cryptography is fast and protects the bulk data. Hashes glue everything together.

Memory hook

"RSA wears two hats; TLS 1.3 took one away." RSA can encrypt a secret (key transport) or sign (authentication). Key transport means whoever later steals the server's private key can decrypt every recorded session, so TLS 1.3 kept only the signing hat. That single change is why TLS 1.3 always has forward secrecy.

#X.509 Certificates, Keys and CSRs

#What's in a certificate

A certificate is a signed statement from a CA: "the holder of this public key is entitled to use these names, from this date to that date". The structure is ASN.1, encoded in DER (binary) and usually shipped as PEM (base64 between -----BEGIN CERTIFICATE----- lines).

Certificate:
  Version: 3
  Serial Number: 04:a1:...              ← unique per CA; ≥ 64 bits of CSPRNG output (CA/B Forum rule)
  Signature Algorithm: ecdsa-with-SHA384
  Issuer: C=US, O=Let's Encrypt, CN=E6  ← must byte-match the issuer cert's Subject
  Validity:
    Not Before: Jun  1 00:00:00 2026 GMT
    Not After : Aug 30 00:00:00 2026 GMT
  Subject: CN=example.com               ← informational only; browsers ignore CN for matching
  Subject Public Key Info:
    Public Key Algorithm: id-ecPublicKey (P-256)
    Public Key: 04:6b:... (65 bytes)
  X509v3 extensions:
    Subject Alternative Name: DNS:example.com, DNS:www.example.com
    Basic Constraints: critical, CA:FALSE
    Key Usage: critical, Digital Signature
    Extended Key Usage: TLS Web Server Authentication
    Authority Key Identifier: 93:27:...
    Subject Key Identifier: 1f:c2:...
    Authority Information Access: CA Issuers - URI:http://e6.i.lencr.org/
    Certificate Policies: 2.23.140.1.2.1    ← CA/B Forum "Domain Validated" policy OID
    CT Precertificate SCTs: (2 SCTs from different log operators)

#Certificate extensions that matter

Critical flagAn extension marked critical must be understood by the client, or the certificate must be rejected. Basic Constraints and Key Usage are normally critical; SAN is critical only when the Subject is empty.

#What's in a private key

Matching a certificate to its private key. They match if they contain the same public key. Compare hashes of the public key, not of the files:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout          | openssl sha256
openssl req  -in req.csr  -noout -pubkey  | openssl sha256   # the CSR should match too

#What's in a CSR

A Certificate Signing Request (PKCS#10) is what you send a CA: your subject, your public key, the extensions you'd like (usually SANs), all signed with your private key. That self-signature is proof of possession: you can't request a certificate for someone else's public key. The private key never leaves your machine.

# New P-256 key + CSR with SANs in one step
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout example.key -out example.csr \
  -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"
openssl req -in example.csr -noout -text -verify      # inspect and check the self-signature

#File formats

openssl x509 -in cert.pem -outform der -out cert.der                    # PEM → DER
openssl x509 -in cert.der -inform der -out cert.pem                     # DER → PEM
openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx
openssl pkcs12 -in bundle.pfx -nodes -out everything.pem                # PFX → PEM (key unencrypted!)
openssl pkcs7 -in chain.p7b -print_certs -out chain.pem                 # P7B → PEM

#Inspecting real certificates

# Show the chain a server actually sends, with SNI
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Decode the leaf
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName,basicConstraints,extendedKeyUsage

#Building a private CA (the lab version)

# 1. Root CA: self-signed, CA:TRUE, long-lived, keep offline
openssl req -x509 -new -newkey ec -pkeyopt ec_paramgen_curve:P-384 -nodes -days 3650 \
  -keyout root.key -out root.pem -subj "/CN=Lab Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign"

# 2. Issuing CA: signed by the root, pathlen:0 = may only sign leaves
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout int.key -out int.csr -subj "/CN=Lab Issuing CA"
openssl x509 -req -in int.csr -CA root.pem -CAkey root.key -days 1825 -out int.pem \
  -extfile <(printf "basicConstraints=critical,CA:TRUE,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign")

# 3. Leaf: CA:FALSE, serverAuth, SANs
openssl x509 -req -in example.csr -CA int.pem -CAkey int.key -days 90 -out example.pem \
  -extfile <(printf "basicConstraints=critical,CA:FALSE\nkeyUsage=critical,digitalSignature\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:example.com,DNS:www.example.com")

openssl verify -CAfile root.pem -untrusted int.pem example.pem           # → example.pem: OK

#Certificate Validation and Chains

#Why there is a chain

Root CA keys are too valuable to use online, so roots sign a handful of intermediate (issuing) CAs, and those sign the end-entity ("leaf") certificates. If an intermediate is compromised, it can be revoked without replacing the root in every device on earth.

flowchart TB
  R["Root CA — self-signed<br/>lives in the client root store<br/>key kept offline in an HSM"]
  I1["Intermediate CA E6<br/>CA:TRUE, pathlen 0"]
  I2["Intermediate CA R11<br/>CA:TRUE, pathlen 0"]
  L1["Leaf: example.com<br/>CA:FALSE, EKU serverAuth"]
  L2["Leaf: api.example.net<br/>CA:FALSE, EKU serverAuth"]
  R --> I1 --> L1
  R --> I2 --> L2

The server sends leaf + intermediates (never needs to send the root: the client must already have it). The client builds a path from the leaf to any root it trusts and validates every link.

#Path building is harder than it looks

#DV, OV and EV

Memory hook

"DV proves the domain, not the company." Every certificate proves control of a name. Only the name is cryptographically checked by the browser. paypa1.com can get a perfectly valid DV certificate. That's why phishing sites have padlocks, and why "look for the padlock" is no longer security advice.

#Revocation

Last verified2026-10

What is this?Revocation is how a CA says "stop trusting this certificate before its expiry date", for example because the private key leaked or the certificate was mis-issued. It is the weakest part of web PKI: every mechanism has failed on privacy, reliability or scale, which is why the industry is moving to short-lived certificates instead.

sequenceDiagram
  participant C as Client
  participant S as Server
  participant O as CA OCSP responder
  Note over S,O: Background, every few hours
  S->>O: OCSP request for my serial
  O-->>S: Signed response "good", valid for days
  Note over C,S: During the handshake
  C->>S: ClientHello + status_request
  S->>C: Certificate + stapled OCSP response
  Note over C: Verify CA signature<br/>on the staple. No call<br/>to the CA, no leak

Important

The soft-fail problemIf an OCSP check times out, almost every client continues rather than breaking the site. But an attacker who has a revoked certificate and sits on the network path can simply block the OCSP request. So plain OCSP stops nothing in exactly the scenario revocation exists for. (Adam Langley's classic line: soft-fail revocation is "like a seat belt that snaps when you crash".)

Where things stand (2026)The CA/Browser Forum made OCSP optional for CAs and requires CRLs. Let's Encrypt removed OCSP URLs from its certificates and shut its OCSP responders down in 2025. Browsers check revocation locally (CRLSets, CRLite). Maximum certificate lifetimes are being cut under ballot SC-081:

#Cipher Suites

What is this?A cipher suite is a named bundle of algorithms the two sides agree to use. In TLS 1.2 the name spells out all four jobs: key exchange, authentication, bulk encryption, and the hash used for the PRF/MAC. TLS 1.3 slimmed it down to just the bulk cipher and hash, because key exchange and authentication are negotiated separately.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  │       │    │    │      │
  │       │    │    │      └── Hash for the PRF (and HMAC in non-AEAD suites)
  │       │    │    └────────── Symmetric cipher + mode
  │       │    └─────────────── Certificate / signature algorithm (authentication)
  │       └──────────────────── Key exchange
  └──────────────────────────── Protocol

TLS_AES_128_GCM_SHA256          ← TLS 1.3: only AEAD cipher + HKDF hash

#The four components

#Forward secrecy, visually

Forward secrecy (often called "perfect forward secrecy", PFS) means that stealing the server's long-term private key later does not let you decrypt traffic you recorded earlier.

#Avoid, accept, prefer

TLS 1.3 needs no such table. It defines only five suites, all AEAD:

#Enumerating what a server supports

nmap --script ssl-enum-ciphers -p 443 example.com        # graded list per protocol version
testssl.sh --protocols --ciphers --vulnerable example.com
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'   # does this one work?
openssl s_client -connect example.com:443 -tls1_3 -ciphersuites TLS_CHACHA20_POLY1305_SHA256

Tip

In TLS 1.2 the server usually decides from the client's list (with "server cipher preference" enabled). Modern guidance (Mozilla "intermediate") lets the client pick among AEAD suites: a phone without AES hardware will choose ChaCha20, which is faster for it.

#The Record Layer

What is this?Everything TLS sends — handshake messages, alerts, application data — is wrapped in records. The record layer splits data into chunks of up to 16 KB, protects each chunk with the current keys, and tags it with a content type.

Handshake messages have their own small header inside handshake records. One handshake message can span several records, and one record can carry several handshake messages.

What you'd see in a hex dump of a ClientHello:

16 03 01 02 00   01 00 01 fc   03 03   a3 4f 9c ... (32 random bytes)
│  │     │       │  │          │
│  │     │       │  │          └─ legacy_version 0x0303
│  │     │       │  └──────────── handshake length 0x0001fc = 508
│  │     │       └─────────────── msg_type 1 = ClientHello
│  │     └─────────────────────── record length 0x0200 = 512
│  └───────────────────────────── record version 0x0301 (compat value)
└──────────────────────────────── content type 0x16 = 22 = handshake

#TLS 1.3 hides the real content type

The nonce for each record is the per-direction IV XORed with a 64-bit sequence number that both sides count but never send. Drop, replay or reorder a record and the tag check fails. This is TLS's anti-replay mechanism within a connection.

#Alerts

Alerts are two bytes: level (1 warning, 2 fatal) and description. In TLS 1.3 everything except close_notify and user_canceled is fatal.

#The TLS 1.2 Handshake

#With RSA key exchange (no forward secrecy)

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  C->>S: ClientHello<br/>version, client random, suites, extensions
  S->>C: ServerHello<br/>chosen suite, server random, session ID
  S->>C: Certificate (RSA public key)
  S->>C: ServerHelloDone
  Note over C: Pick 48-byte<br/>pre-master secret,<br/>encrypt to RSA key
  C->>S: ClientKeyExchange (encrypted pre-master)
  C->>S: ChangeCipherSpec
  C->>S: Finished (encrypted)
  S->>C: ChangeCipherSpec
  S->>C: Finished (encrypted)
  Note over C,S: 2 round trips before application data

#With ECDHE (forward secrecy)

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  C->>S: ClientHello<br/>suites, supported_groups, sig algs
  S->>C: ServerHello (ECDHE_RSA suite)
  S->>C: Certificate
  S->>C: ServerKeyExchange<br/>curve + ephemeral public key<br/>signed with cert private key
  S->>C: ServerHelloDone
  Note over C: Verify signature,<br/>make own ephemeral<br/>key, derive secret
  C->>S: ClientKeyExchange (client ephemeral public key)
  C->>S: ChangeCipherSpec + Finished
  S->>C: ChangeCipherSpec + Finished

The signature in ServerKeyExchange is the authentication. It covers both randoms and the server's DH public key, so an attacker can't swap in their own DH key without the certificate's private key.

#From secret to keys (TLS 1.2)

#Session resumption

A full handshake costs 2 round trips plus public-key operations. Resumption reuses the master secret from an earlier session in an abbreviated handshake (1 round trip, no certificate, no key exchange).

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: ClientHello + session ticket (or session ID)
  S->>C: ServerHello (same session)
  S->>C: ChangeCipherSpec + Finished
  C->>S: ChangeCipherSpec + Finished
  Note over C,S: 1 RTT, no Certificate, no key exchange

#Mutual TLS (client certificates)

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  C->>S: ClientHello
  S->>C: ServerHello, Certificate, ServerKeyExchange
  S->>C: CertificateRequest<br/>acceptable CAs + sig algs
  S->>C: ServerHelloDone
  C->>S: Certificate (client cert, in the clear in 1.2)
  C->>S: ClientKeyExchange
  C->>S: CertificateVerify<br/>signature over handshake so far
  C->>S: ChangeCipherSpec + Finished
  S->>C: ChangeCipherSpec + Finished

Warning

In TLS 1.2 the client certificate is sent unencrypted, so a passive observer learns the client's identity (name, email, device ID). TLS 1.3 encrypts it. This matters for mTLS-based device identity and zero-trust deployments.

#Renegotiation

TLS 1.2 allowed a new handshake inside an existing connection, used for "this URL needs a client certificate" or rekeying. It caused CVE-2009-3555 (see attacks below) and DoS issues. The renegotiation_info extension (RFC 5746) fixed the injection flaw. TLS 1.3 removed renegotiation entirely.

#TLS Extensions

Extensions are typed fields at the end of ClientHello/ServerHello that let TLS grow without new versions. Each side ignores extension types it doesn't recognise, which is what makes them safe to add. A server may only send an extension the client offered.

#Decrypting and Inspecting TLS

There are exactly two ways to read TLS traffic you captured: have the session keys, or be in the middle of the connection.

# SSLKEYLOGFILE format (NSS key log) — one line per secret
CLIENT_RANDOM                    <client_random_hex> <master_secret_hex>      ← TLS 1.2
CLIENT_HANDSHAKE_TRAFFIC_SECRET  <client_random_hex> <secret_hex>             ← TLS 1.3
SERVER_HANDSHAKE_TRAFFIC_SECRET  <client_random_hex> <secret_hex>
CLIENT_TRAFFIC_SECRET_0          <client_random_hex> <secret_hex>
SERVER_TRAFFIC_SECRET_0          <client_random_hex> <secret_hex>
EXPORTER_SECRET                  <client_random_hex> <secret_hex>

SSLKEYLOGFILE=$HOME/tls-keys.log curl -s https://example.com -o /dev/null
# Wireshark: Preferences → Protocols → TLS → (Pre)-Master-Secret log filename
# Useful display filters:
#   tls.handshake.type == 1                          ClientHellos
#   tls.handshake.extensions_server_name == "example.com"
#   tls.record.content_type == 21                    alerts
#   tls.handshake.ja4                                JA4 fingerprints (recent Wireshark)

Caution

A key log file is the session's crown jewels. Malware that sets SSLKEYLOGFILE system-wide gets silent decryption of every browser session. Hunt for that environment variable on endpoints, and never leave it set on a workstation after debugging.

#TLS Defenses: HSTS, CAA and Certificate Transparency

#HSTS (HTTP Strict Transport Security, RFC 6797)

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

HPKP (HTTP Public Key Pinning, RFC 7469) tried to go further by pinning keys, but sites bricked themselves and attackers could pin hostile keys ("ransom pinning"). Chrome removed it in 2018–2019. Certificate Transparency replaced pinning as the web's defence against rogue certificates.

#CAA (Certification Authority Authorization, RFC 8659)

A DNS record that says which CAs may issue for your domain. Since September 2017 every public CA must check it before issuing.

example.com.  CAA 0 issue     "letsencrypt.org"                 ; only Let's Encrypt may issue
example.com.  CAA 0 issuewild ";"                               ; nobody may issue wildcards
example.com.  CAA 0 iodef     "mailto:security@example.com"     ; report violations here
example.com.  CAA 0 issue     "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123"   ; RFC 8657: only *our* account

CAA is a check on honest CAs, not on attackers: a compromised CA can ignore it. Combine it with CT monitoring.

#Certificate Transparency (RFC 6962, v2 RFC 9162)

What is this?A set of public, append-only logs that every publicly trusted certificate must be submitted to. Anyone can search them, so a domain owner can see every certificate ever issued for their names. Browsers refuse certificates that can't prove they were logged.

Why a Merkle tree?The log is a binary hash tree. Each leaf is a hash of one certificate, and each parent is the hash of its two children. The root hash (signed as the Signed Tree Head, STH) commits to every entry.

                    Root = H(H12 ‖ H34)          ← signed tree head (STH)
                   /                   \
           H12 = H(H1 ‖ H2)      H34 = H(H3 ‖ H4)
            /        \             /        \
         H1          H2         H3          H4
       cert A      cert B     cert C      cert D

Inclusion proof for cert C: give the client H4 and H12.
  Client computes H3 = hash(C) → H34 = H(H3 ‖ H4) → Root = H(H12 ‖ H34), compares with the signed STH.
  Proof size = log2(n) hashes: ~20-30 hashes even for a billion certificates.

Consistency proof: shows tree of size 4 is a prefix of tree of size 8, i.e. the log only appended
and never rewrote history.

Memory hook

"CT doesn't prevent mis-issuance; it makes it impossible to hide." A rogue CA can still sign a certificate for your domain. But to be accepted by browsers it has to be logged publicly, and your monitor fires within hours. DigiNotar (2011) went undetected for weeks. Under CT, the same attack is visible to the world.

#Major TLS Attacks and Failures

Each of these broke something specific, and each fix is now a rule in modern configs.

#Insecure renegotiation, step by step

sequenceDiagram
  participant V as Victim client
  participant A as Attacker (MITM)
  participant S as Server
  A->>S: Full TLS handshake (as the attacker)
  A->>S: "GET /transfer?to=attacker" + "X-Ignore: " (no newline)
  V->>A: ClientHello (victim starts TLS)
  A->>S: Forwards it as a RENEGOTIATION in the attacker's session
  S-->>V: Handshake completes, encrypted end to end with the victim
  V->>S: "GET /home" + victim's cookie
  Note over S: Server sees ONE<br/>request: attacker's<br/>line + victim's<br/>cookie

The server glued the attacker's plaintext prefix onto the victim's authenticated request, because nothing tied the renegotiated handshake to the connection it happened inside. RFC 5746 fixed this by making each renegotiation include the previous handshake's Finished values.

#TLS 1.3: What Changed and Why

What is this?TLS 1.3 (RFC 8446, 2018) is less an upgrade than a cleanup. It removes every feature that produced a major attack, makes forward secrecy mandatory, encrypts most of the handshake, and cuts a full handshake to one round trip.

#TLS 1.2 vs TLS 1.3

Memory hook

TLS 1.3 is 1-RTT because the client "guesses" and is almost always right. In TLS 1.2 the client first asks which key-exchange to use, waits, then sends its key — two round trips of negotiating. TLS 1.3 collapses this: there's only one key-exchange family (ECDHE), so the client just sends its ECDHE key share in the very first message (the ClientHello) without asking. The server replies with its own share and is already able to encrypt the certificate. Mnemonic: 1.2 negotiates-then-acts; 1.3 acts immediately because there's nothing left to negotiate. That same "send key share upfront" is also why the certificate is now encrypted (a passive eavesdropper can't see which site you visited from the cert) and why forward secrecy is automatic (ECDHE every time, RSA key transport deleted).

#The full handshake

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  C->>S: ClientHello<br/>supported_versions, key_share,<br/>signature_algorithms, SNI, ALPN
  S->>C: ServerHello<br/>key_share, supported_versions
  Note over C,S: Handshake keys derived — all below is encrypted
  S->>C: EncryptedExtensions (ALPN, ...)
  S->>C: CertificateRequest (only for mTLS)
  S->>C: Certificate
  S->>C: CertificateVerify
  S->>C: Finished
  Note over S: May already send<br/>data (0.5-RTT)
  C->>S: Certificate + CertificateVerify (only for mTLS)
  C->>S: Finished
  Note over C,S: Application traffic keys in use
  S-->>C: NewSessionTicket (any time after)

#When the client guessed wrong: HelloRetryRequest

If the client's key share is for a group the server won't use (say the client sent only X25519MLKEM768 and the server only does P-256), the server replies with a HelloRetryRequest. It's a ServerHello whose random field is the fixed value SHA-256("HelloRetryRequest"). The cost is one extra round trip.

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: ClientHello, key_share X25519MLKEM768
  S->>C: HelloRetryRequest<br/>"use secp256r1" + cookie
  C->>S: ClientHello again<br/>key_share secp256r1 + cookie
  S->>C: ServerHello ... Finished
  C->>S: Finished

The cookie extension lets the server stay stateless during the retry (useful against DoS, and essential in DTLS/QUIC).

#Renegotiation is gone — what replaced it

#Middleboxes, GREASE and the version number that lies

When TLS 1.3 was tested on the real internet, a few percent of connections failed because firewalls and inspection boxes choked on anything unfamiliar. The fix was to make TLS 1.3 look like a TLS 1.2 session resumption:

Downgrade protectionA TLS 1.3 server forced down to TLS 1.2 puts the bytes 44 4F 57 4E 47 52 44 01 ("DOWNGRD\x01") at the end of ServerHello.random (...00 for TLS 1.1 or lower). The random is covered by the signature, so an attacker can't remove it, and a 1.3-capable client that sees it aborts.

#Forward secrecy and the visibility debate

Mandatory forward secrecy broke a long-standing enterprise practice: passive decryption by loading the server's RSA private key into a monitoring appliance. With ECDHE there's nothing to load. Organisations now choose between:

#Decrypting TLS 1.3

The only options are the key log file or being an active MITM. The RSA-private-key trick does not work, not even with an RSA certificate, because RSA only signs in TLS 1.3.

#TLS 1.3 Under the Hood

#The key schedule

TLS 1.3 derives every key from three chained secrets using HKDF (RFC 5869). HKDF-Extract concentrates entropy into a fixed-size secret. HKDF-Expand-Label stretches a secret into labelled outputs (all labels are prefixed with "tls13 "). Each stage mixes in new input and hashes of the handshake transcript so far.

        PSK (or zeros)
             │
  0 ──▶ HKDF-Extract ══▶ EARLY SECRET ──┬──▶ binder_key
             │                          ├──▶ client_early_traffic_secret     ← 0-RTT
             │                          └──▶ early_exporter_master_secret
             ▼
      Derive-Secret("derived")
             │
 (EC)DHE ─▶ HKDF-Extract ══▶ HANDSHAKE SECRET ──┬──▶ client_handshake_traffic_secret
             │                                  └──▶ server_handshake_traffic_secret
             ▼
      Derive-Secret("derived")
             │
  0 ──▶ HKDF-Extract ══▶ MASTER SECRET ──┬──▶ client_application_traffic_secret_0
                                         ├──▶ server_application_traffic_secret_0
                                         ├──▶ exporter_master_secret
                                         └──▶ resumption_master_secret

Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Transcript-Hash(Messages), Hash.length), and every label is prefixed with "tls13 " on the wire.

What the signatures and MACs cover

#Session resumption with PSKs

After the handshake the server sends one or more NewSessionTicket messages. Each ticket identifies a PSK derived from resumption_master_secret. The ticket blob itself is opaque to the client: usually the server's encrypted session state.

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  C->>S: ClientHello<br/>key_share + psk_key_exchange_modes psk_dhe_ke<br/>pre_shared_key (ticket identity + binder)
  S->>C: ServerHello<br/>pre_shared_key (selected) + key_share
  S->>C: EncryptedExtensions
  S->>C: Finished
  C->>S: Finished
  Note over C,S: No Certificate / CertificateVerify<br/>PSK proves identity, (EC)DHE keeps forward secrecy

#0-RTT early data

A returning client can encrypt application data with client_early_traffic_secret (derived from the PSK) and send it in the same flight as the ClientHello.

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  C->>S: ClientHello + early_data + pre_shared_key
  C->>S: Early data: GET /home (0-RTT keys)
  S->>C: ServerHello + EncryptedExtensions (early_data accepted)
  S->>C: Finished
  S-->>C: Response to GET /home (0.5-RTT)
  C->>S: EndOfEarlyData + Finished

Caution

0-RTT data can be replayedIt's encrypted under keys derived only from the PSK and the ClientHello, with no fresh server input. An attacker can capture that first flight and send it again, to the same server or another node in the fleet. It also has no forward secrecy against PSK compromise.

#Mutual TLS in 1.3

The server's CertificateRequest comes inside the encrypted flight, and the client's Certificate + CertificateVerify are encrypted too, so a passive observer no longer learns client identities. The request can carry signature_algorithms, certificate_authorities (acceptable CAs) and oid_filters (required certificate extensions). A client with no suitable certificate sends an empty Certificate; the server decides whether to abort (certificate_required, alert 116).

#TLS 1.3 Extensions

In TLS 1.3, extensions carry most of the negotiation, and each extension may only appear in specific messages: CH (ClientHello), SH (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR (CertificateRequest), NST (NewSessionTicket), HRR (HelloRetryRequest).

#TLS Fingerprinting (JA3 / JA4)

Last verified2026-06

What is this?When a client opens a TLS connection, its very first message — the ClientHello — advertises how it wants to talk: which TLS version, which cipher suites, which extensions, which elliptic-curve groups, and so on. Different software builds that list in its own distinctive order. A Python requests script, Chrome, and a piece of malware each produce a recognisably different ClientHello. TLS fingerprinting turns that ClientHello into a short hash so you can identify the client software without decrypting anything.

The key point: the ClientHello is sent in the clear, before encryption starts (it has to be — it's negotiating the encryption). So a network sensor that can't read your encrypted traffic can still read the fingerprint. You're identifying the tool, not the content.

Why it mattersEncryption blinds the defender to payload, but the handshake metadata still leaks. A real browser and a malware C2 client both speak TLS, but they build their ClientHello differently — so the fingerprint distinguishes "Chrome on macOS" from "Cobalt Strike's default profile" or "a Go program" even though both connections are encrypted. It's a top-of-Pyramid-of-Pain signal: it targets the attacker's tooling, not an IP or hash they can trivially change.

How it works

JA3 (client):  hash of  TLSVersion,Ciphers,Extensions,EllipticCurves,ECPointFormats
               taken from the ClientHello, joined with "-" and "," then MD5'd.

  ClientHello fields ──▶ "771,4865-4866-...,0-23-65281-10-11-...,29-23-24,0"
                     ──▶ MD5 ──▶ e7d705a3286e19ea42f587b344ee6865

JA3S (server): the same idea applied to the ServerHello (version, chosen cipher,
               extensions). JA3 + JA3S together fingerprint *both ends* of a session.

JA4 fingerprint, decoded:
  t 13 d 15 16 h2 _ 8daaf6152771 _ b186095e22b6
  │  │ │  │  │  │       │              │
  │  │ │  │  │  │       │              └─ hash of sorted extensions
  │  │ │  │  │  │       └──────────────── hash of sorted cipher suites
  │  │ │  │  │  └─ ALPN (h2 = HTTP/2)
  │  │ │  │  └──── extension count (16)
  │  │ │  └─────── cipher count (15)
  │  │ └────────── SNI present (d = domain)
  │  └──────────── TLS version (13 = TLS 1.3, read from the supported_versions
  │                extension — not the legacy record version, which 1.3 pins to 1.2)
  └─────────────── transport (t = TCP, q = QUIC)

Security angle

#Hash-based MAC (HMAC)

HMAC(key, message) = Hash((key XOR opad) ∥ Hash((key XOR ipad) ∥ message))

• Prevents length extension attacks (which plain Hash(key ∥ message) is vulnerable to)
• Security depends entirely on key secrecy (not on collision resistance of underlying hash)
• HMAC-SHA256 is the current standard (used in HKDF, JWT HS256, AWS request signing)

#Key Derivation Functions (KDF)

Why memory-hard functions matterGPU/ASIC attacks on simple iteration (PBKDF2) are viable because parallel hardware is cheap. Memory-hard functions require large memory per hash, limiting parallelism.

#Quantum Threat and Post-Quantum Cryptography

Grover's algorithmSpeeds up brute-force search. Halves effective key length.

• AES-128 → 64-bit security (borderline)
• AES-256 → 128-bit security (still safe)
• SHA-256 → 128-bit collision resistance (safe)

Shor's algorithmEfficiently solves integer factoring and ECDLP.

• Breaks RSA, DH, ECDH, ECDSA completely when large-scale quantum computer exists

NIST Post-Quantum Standards (2024)

In TLS todaythe hybrid group X25519MLKEM768 (classical X25519 combined with ML-KEM-768) is on by default in Chrome (since Chrome 131, November 2024), Firefox, Safari and major CDNs, so a large and growing share of web traffic is already protected against "harvest now, decrypt later". It's a hybrid on purpose: the session stays secure as long as either component is unbroken. The key share is ~1.2 KB, which pushes the ClientHello past one packet and has broken a few middleboxes. Post-quantum signatures (ML-DSA) in certificates are not yet deployed on the public web: certificate chains would grow by several kilobytes.

#Quick Reference: Where Algorithms Are Used