TLS

TLS is the protocol that gives traffic confidentiality, integrity, and authenticity (HTTPS and much more). This card covers how the handshake works, how to audit a TLS configuration, and the historical attacks that explain why TLS 1.3 is recommended today.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello (suites, random)
    S-->>C: ServerHello (chosen suite, random)
    S-->>C: Certificate (X.509 chain)
    S-->>C: ServerHelloDone
    C->>S: ClientKeyExchange (premaster encrypted with public key)
    C->>S: ChangeCipherSpec + Finished
    S-->>C: ChangeCipherSpec + Finished
    Note over C,S: Encrypted channel established

Handshake (short version)

TLS 1.2
  ClientHello (cipher suites, extensions) -> ServerHello (chosen suite) + certificate
  key exchange (ECDHE) -> both derive the session key -> Finished
TLS 1.3 (RFC 8446)
  1-RTT handshake (optional 0-RTT); ONLY AEAD suites with PFS (ECDHE)
  removes RSA key exchange, CBC, RC4, compression, renegotiation -> much simpler and safer

PFS (Perfect Forward Secrecy): with ECDHE, compromising the server’s private key does not decrypt captured past traffic. The key reason to require ECDHE.

What to audit (enumeration)

testssl.sh https://host            # version, suites, PFS, known vulns, cert
sslscan host:443                   # supported suites quickly
nmap --script ssl-enum-ciphers -p443 host
openssl s_client -connect host:443 -tls1_2   # manual handshake/cert inspection
# Qualys SSL Labs for an external grade (public sites)

Red flags: SSLv3/TLS1.0/1.1 enabled, weak RC4/3DES/CBC, no PFS, expired cert or incomplete chain, RSA key < 2048.

Historical attacks (why TLS evolved)

BEAST (2011)     CBC + predictable IV in TLS1.0
CRIME/BREACH     compression + injection -> recover cookies/tokens by size
POODLE (2014)    downgrade to SSLv3 + CBC padding oracle
Heartbleed (2014) CVE-2014-0160: OpenSSL memory leak (keys, data) via a heartbeat
                  bug, NOT a protocol flaw -> read server memory
FREAK/Logjam     downgrade to weak "export" keys (512-bit RSA/DH)
DROWN (2016)     reusing a key with vulnerable SSLv2 breaks TLS
Sweet32          block collision in 3DES (64-bit block) with many requests

Almost all are mitigated by: disabling old versions/suites, no TLS compression, and preferring TLS 1.3.

MITM in TLS (lab / client pentest)

# if the CLIENT doesn't validate the certificate well (see crypto-pki):
mitmproxy / burp as a proxy -> presents its own cert -> if the client accepts it, full MITM
# useful to analyze mobile/IoT apps; with pinning you need a bypass (Frida) in an authorized setup

Tools

testssl.sh, sslscan, nmap ssl-enum-ciphers, openssl s_client (auditing).
mitmproxy / Burp (intercept), Wireshark (analyze the handshake, with session keys to decrypt).

Defense

TLS 1.3 (and 1.2 only with AEAD + ECDHE suites); disable SSLv2/3, TLS 1.0/1.1, RC4, 3DES, CBC.
HSTS (forces HTTPS), OCSP stapling, valid CA certs with a complete chain, keys ≥ 2048/ECC.
No TLS compression; automated renewal/rotation (ACME/Let’s Encrypt); monitor with CT.
On your own clients: strict validation and, where applicable, pinning.

CVEs and real-world cases

Heartbleed (CVE-2014-0160): mass theft of keys and data from OpenSSL servers in 2014.
POODLE (CVE-2014-3566), DROWN (CVE-2016-0800), Logjam, FREAK: downgrade/legacy.
ROBOT (2017): Bleichenbacher over RSA key exchange still present on real appliances.

Testing checklist

Scan with testssl.sh/sslscan: versions and suites
SSLv3/TLS1.0-1.1, RC4, 3DES, CBC, or no PFS?
Verify the certificate: validity, chain, SAN, key size
Vulnerable to Heartbleed/POODLE/DROWN/ROBOT? (testssl flags it)
HSTS present? HTTP→HTTPS redirect?
Own clients: MITM to check validation/pinning
Prefer and verify TLS 1.3 support

TLS