# Security Tls Fundamentals > TLS Fundamentals - Skill: `intense-visions/security-tls-fundamentals` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add intense-visions/security-tls-fundamentals` - Raw SKILL.md: https://api.skillmd.com/api/skills/intense-visions/security-tls-fundamentals/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: Intense-Visions (https://skillmd.com/u/intense-visions) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/intense-visions/security-tls-fundamentals --- # TLS Fundamentals > TLS 1.3 with ECDHE key exchange, AES-256-GCM or ChaCha20-Poly1305 ciphers, and valid > certificates -- the minimum bar for all network communication ## When to Use - Setting up HTTPS for a web application or API - Configuring TLS cipher suites on a server or load balancer - Diagnosing TLS handshake failures or certificate errors - Evaluating whether to support TLS 1.2 alongside TLS 1.3 - Implementing certificate pinning or transparency monitoring - Reviewing a system's transport security posture ## Threat Context Without TLS, all network traffic is plaintext -- readable and modifiable by anyone on the network path (ISP, WiFi operator, compromised router, government surveillance). Man-in-the-middle (MITM) attacks can intercept credentials, session tokens, and sensitive data. Historical TLS vulnerabilities demonstrate that protocol version and configuration matter enormously: - **POODLE** (2014, CVE-2014-3566): Exploited CBC padding in SSL 3.0 and TLS 1.0 to decrypt HTTPS traffic byte-by-byte. Forced the deprecation of SSL 3.0. - **BEAST** (2011, CVE-2011-3389): Exploited a predictable IV in TLS 1.0 CBC mode to decrypt data via chosen-plaintext attack. - **CRIME/BREACH** (2012-2013): Exploited TLS-level and HTTP-level compression to extract secrets (session cookies) from encrypted traffic by observing response size changes. - **Heartbleed** (2014, CVE-2014-0160): A buffer over-read in OpenSSL's heartbeat extension leaked up to 64KB of server memory per request -- including private keys, session tokens, and user credentials. Affected 17% of the internet's HTTPS servers. - **FREAK** (2015, CVE-2015-0204): Forced downgrade to export-grade 512-bit RSA, breakable in hours. - **Logjam** (2015, CVE-2015-4000): Forced downgrade to 512-bit Diffie-Hellman, breakable by nation-state attackers. TLS 1.3 eliminates all known protocol-level attacks present in TLS 1.0-1.2 by removing every insecure cryptographic option from the protocol specification itself. ## Instructions 1. **Deploy TLS 1.3 as the primary protocol.** TLS 1.3 (RFC 8446, 2018) removes all insecure cryptographic options from the protocol: no RSA key exchange (no forward secrecy), no CBC mode (padding oracle risk), no static DH, no custom DH groups, no RC4, no 3DES, no MD5, no SHA-1 in signatures. The only key exchange is ephemeral Diffie-Hellman (ECDHE or DHE). The only ciphers are AEAD: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305. The handshake completes in 1 round trip (1-RTT) instead of 2 (TLS 1.2), reducing latency by one full network round trip. 2. **Support TLS 1.2 as fallback only when required.** Some clients (older Android, enterprise proxies, legacy IoT devices) do not support TLS 1.3. If TLS 1.2 must be supported, restrict cipher suites to those providing both forward secrecy and AEAD: - `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` - `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` - `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` - `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` All require ECDHE (forward secrecy) and AEAD ciphers. Reject all non-ECDHE and non-AEAD cipher suites. 3. **Disable TLS 1.0 and TLS 1.1 completely.** Both are deprecated by IETF (RFC 8996, 2021). TLS 1.0 is vulnerable to BEAST and POODLE. TLS 1.1 uses obsolete cipher constructions and has no security advantage over TLS 1.2. PCI DSS 3.2+ requires TLS 1.2 as the minimum for cardholder data environments. All major browsers dropped TLS 1.0/1.1 support in 2020. 4. **Use valid certificates from a trusted Certificate Authority.** Obtain certificates from Let's Encrypt (free, automated via ACME protocol), or a commercial CA for extended validation. Every certificate must: match the domain name via Subject Alternative Name (SAN), be within its validity period, chain to a trusted root CA in the client's trust store, and use RSA-2048+ or ECDSA P-256+ keys. Prefer ECDSA certificates -- they produce smaller signatures and faster handshakes than equivalent-security RSA certificates. 5. **Enable HSTS (HTTP Strict Transport Security).** The `Strict-Transport-Security` header instructs browsers to only connect via HTTPS, preventing SSL stripping attacks where a MITM downgrades HTTPS to HTTP. Set `max-age=31536000; includeSubDomains; preload` for maximum protection. Submit to the HSTS preload list (hstspreload.org) so browsers enforce HTTPS before the first connection. See `security-hsts-preloading` for preload list submission details. 6. **Understand the TLS 1.3 handshake sequence.** Client sends ClientHello containing supported cipher suites and key shares for ECDHE. Server responds with ServerHello (selected cipher suite and key share), then immediately sends encrypted EncryptedExtensions, Certificate, CertificateVerify (proving possession of the private key), and Finished. Client verifies the certificate chain, computes the shared secret from the key exchange, sends its own Finished message. Total: 1 round trip to first application data. With 0-RTT resumption, returning clients can send application data on the very first packet, at the cost of replay vulnerability for that 0-RTT data. 7. **Monitor Certificate Transparency logs.** Certificate Transparency (CT) is a public, append-only log of all certificates issued by participating CAs. Monitor CT logs for your domains using crt.sh, Google's CT monitoring, or commercial services (Censys, SSLMate). CT monitoring detects misissued certificates (a CA issues a cert for your domain to someone else) and unauthorized certificates (an internal CA issues a cert that should not exist). React to unexpected certificates immediately -- they indicate either a compromised CA or an attacker with CA access. ## Details - **Cipher suite anatomy (TLS 1.3 vs 1.2)**: TLS 1.3 cipher suite names are simplified: `TLS_AES_256_GCM_SHA384` specifies only the AEAD cipher and hash function. Key exchange is always ECDHE, negotiated separately via the `supported_groups` extension, so it does not appear in the cipher suite name. TLS 1.2 cipher suite names encode everything: `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` means ECDHE key exchange, RSA authentication, AES-256-GCM encryption, SHA-384 PRF. This difference reflects TLS 1.3's design philosophy: fewer choices, all of them secure. - **Forward secrecy and why it matters**: Ephemeral key exchange (ECDHE) generates a fresh key pair for every session. The session key is derived from the ephemeral exchange, and after the session ends, the ephemeral private key is discarded. If the server's long-term private key (the certificate key) is later compromised -- through theft, legal compulsion, or cryptanalytic breakthrough -- past session keys cannot be recovered because they were never derived from the long-term key. Without forward secrecy (static RSA key exchange in TLS 1.2), a compromised certificate key decrypts all previously recorded traffic. Nation-state adversaries are known to record encrypted traffic for later decryption; forward secrecy renders this strategy ineffective. - **0-RTT resumption: performance vs security tradeoff**: TLS 1.3 supports 0-RTT data on resumed connections, where the client sends encrypted application data alongside the ClientHello using a pre-shared key from a previous session. This eliminates the handshake round trip entirely for returning clients. However, 0-RTT data is fundamentally replayable -- an attacker can capture the first flight and replay it to the server. Only use 0-RTT for idempotent requests (GET, HEAD). Never permit 0-RTT for state-changing operations (POST, PUT, DELETE, financial transactions). Most server implementations reject 0-RTT by default or limit it to explicitly marked endpoints. If latency is not critical, disable 0-RTT entirely. - **Certificate chain validation in detail**: The client performs five verification steps: (1) the leaf certificate's Subject Alternative Name matches the requested domain, (2) the certificate is within its validity period (notBefore to notAfter), (3) each certificate in the chain is signed by the issuer certificate above it, (4) the chain terminates at a root CA in the client's trust store, (5) no certificate in the chain appears on a Certificate Revocation List (CRL) or has been revoked via OCSP (Online Certificate Status Protocol). OCSP stapling allows the server to include a signed, timestamped OCSP response in the TLS handshake, so the client does not need to contact the CA separately. - **ChaCha20-Poly1305 vs AES-GCM**: AES-GCM is faster on hardware with AES-NI instructions (most modern x86 and ARM processors). ChaCha20-Poly1305 is faster on devices without AES hardware acceleration (older mobile devices, IoT). Both provide equivalent security. Supporting both cipher suites ensures optimal performance across all client hardware. Server-side cipher preference should select AES-GCM when the client supports AES-NI and ChaCha20-Poly1305 otherwise. ## Anti-Patterns 1. **Supporting SSL 3.0, TLS 1.0, or TLS 1.1.** These protocol versions are vulnerable to known attacks (POODLE, BEAST, FREAK, Logjam) and have been formally deprecated by the IETF. Disable them completely. There is no legitimate reason to support them in 2024+. 2. **Allowing non-AEAD cipher suites in TLS 1.2.** CBC-mode ciphers are vulnerable to padding oracle attacks (Lucky Thirteen, POODLE). RC4 is cryptographically broken. Only permit GCM or ChaCha20-Poly1305 AEAD cipher suites. If a client cannot negotiate an AEAD cipher, the client is too old to trust. 3. **Self-signed certificates in production.** Self-signed certificates provide encryption but no identity verification. Every client must disable certificate validation to connect, which makes MITM attacks trivial -- the attacker presents their own self-signed certificate and the client accepts it. Use Let's Encrypt for free, automated, trusted certificates. 4. **Ignoring certificate expiry and failing to automate renewal.** Let's Encrypt certificates expire after 90 days. Commercial certificates typically last 1 year. Certificate expiry outages are entirely preventable through automation (certbot, Caddy's automatic HTTPS, cloud provider managed certificates). A certificate expiry outage in production indicates an operational maturity failure, not a technical limitation. 5. **TLS termination at the load balancer with plaintext backend traffic.** Terminating TLS at the edge and forwarding plaintext HTTP to backend servers means any compromise of the internal network exposes all traffic in cleartext. East-west traffic within a data center is a common attack vector after initial compromise. Re-encrypt traffic between the load balancer and backends (TLS to backends), or implement end-to-end TLS where the application server terminates TLS directly. At minimum, ensure the internal network is segmented and monitored. 6. **Disabling certificate verification in client code.** Setting `verify=False`, `rejectUnauthorized: false`, or equivalent in HTTP clients to "make it work" during development, then shipping that code to production. This disables all protection against MITM attacks. Fix the certificate issue instead of disabling verification. 7. **Hardcoding cipher suites without a maintenance plan.** Cipher suite recommendations evolve as attacks are discovered. A hardcoded cipher suite list from 2018 may include ciphers that are now deprecated. Use a maintained configuration generator (Mozilla SSL Configuration Generator) and review cipher suite configuration annually.