# HTTPS / TLS (Transport Layer Security) Confidence: high Last verified: 2026-05-22 Generation: human_only ## TL;DR HTTPS (HTTP over TLS) provides three essential security properties: **confidentiality** (encryption prevents eavesdropping), **integrity** (tamper detection), and **authentication** (server identity verified via X.509 certificates). TLS 1.3 (RFC 8446, 2018) is the current standard — it reduced the handshake from 2 to 1 round trip (0-RTT on resumption), removed all obsolete algorithms (RSA key exchange, CBC-mode ciphers, SHA-1, MD5), and mandates forward secrecy (all key exchanges use ECDHE). As of 2026, over 90% of pages loaded in Chrome use HTTPS (Google Transparency Report), and Let's Encrypt has issued more than 400 million free certificates. ## Core Explanation TLS operates between the transport layer (TCP) and the application layer (HTTP). The lifecycle of a TLS connection: ### TLS 1.3 Handshake (1-RTT) ``` Client Server |--- ClientHello ----------------------->| (1) Supported ciphers, key share (ECDHE), SNI |<-- ServerHello, EncryptedExtensions ----| (2) Chosen cipher, server key share, certificate |<-- Certificate, CertVerify, Finished ---| All server messages after ServerHello are ENCRYPTED |--- Finished -------------------------->| (3) Client authentication completed |<===== ENCRYPTED APPLICATION DATA =====>| ``` **0-RTT Resumption**: For previously visited servers, the client can send application data immediately in the first flight, derived from a pre-shared key (PSK) established in a prior session. Total: ClientHello + data → Server response. This eliminates the round-trip entirely but provides weaker forward secrecy for 0-RTT data (replay protection relies on server-side anti-replay mechanisms). Compare to TLS 1.2 (2-RTT): ClientHello → ServerHello + Certificate → ClientKeyExchange + ChangeCipherSpec → Finished. The two extra round trips added 100-300ms of latency. TLS 1.3's single round trip is a major performance improvement. ## Detailed Analysis ### Key Cryptographic Properties | Property | How TLS Provides It | |----------|-------------------| | **Confidentiality** | Symmetric encryption (AES-GCM, ChaCha20-Poly1305) of all application data | | **Integrity** | AEAD ciphers (Authenticated Encryption with Associated Data) — encrypt AND authenticate in one operation | | **Authentication** | X.509 certificate chain: server's certificate signed by a Certificate Authority (CA), verified via chain of trust to a root CA in the browser's trust store | | **Forward Secrecy** | Mandatory in TLS 1.3: all key exchanges use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). Compromising the server's long-term private key does not decrypt past sessions because ephemeral keys are discarded after each session | ### TLS 1.3: What Was Removed TLS 1.3 took the unusual step of *removing* features that made TLS 1.2 complex and vulnerable: | Removed Feature | Why | |----------------|-----| | RSA key exchange | Not forward secret — server's private key can decrypt ALL past sessions | | CBC-mode ciphers | Vulnerable to padding oracle attacks (Lucky13, POODLE) | | RC4 stream cipher | Completely broken | | SHA-1 hash | Collision demonstrated (SHAttered, 2017) | | MD5 hash | Collision attacks trivial | | Static DH key exchange | Not forward secret | | Compression | CRIME attack (2012) — compressed length leaks plaintext | | Renegotiation | Triple Handshake attack | TLS 1.3 supports only 5 cipher suites (vs. dozens in TLS 1.2), all of which are AEAD ciphers: 1. `TLS_AES_128_GCM_SHA256` (most widely deployed) 2. `TLS_AES_256_GCM_SHA384` (higher security margin) 3. `TLS_CHACHA20_POLY1305_SHA256` (optimized for mobile/ARM processors) 4. `TLS_AES_128_CCM_SHA256` (constrained environments, IoT) 5. `TLS_AES_128_CCM_8_SHA256` (8-byte authentication tag, IoT) ### X.509 Certificates Server authentication relies on X.509 certificates, which bind a domain name to a public key. A certificate contains: - **Subject**: The domain name (Common Name or Subject Alternative Name) - **Issuer**: The Certificate Authority that signed it - **Validity period**: Not Before / Not After dates - **Public key**: The server's public key - **Signature**: CA's digital signature over the certificate contents **Certificate Chain Verification**: Browser receives server certificate → checks it was signed by an intermediate CA → checks intermediate was signed by a root CA → root CA is in the browser's trust store (pre-installed). If any link in the chain fails, the browser shows a security warning. **Certificate Transparency** (RFC 6962, 2013): All certificates must be publicly logged. Domain owners can monitor CT logs to detect mis-issued certificates. Chrome requires CT for all new certificates since 2018. ### Deployment Status | Metric | Value (2026) | Source | |--------|:------------:|--------| | HTTPS adoption (Chrome pageloads) | >90% | Google Transparency Report | | TLS 1.3 adoption | ~70% of HTTPS connections | IETF/Cloudflare data | | Let's Encrypt certificates issued | 400M+ | Let's Encrypt Stats | | Let's Encrypt active domains | 300M+ | Let's Encrypt Stats | | Average certificate lifetime | 90 days | ACME standard | Let's Encrypt (founded 2014, operated by ISRG) was the primary driver of HTTPS adoption, providing free, automated certificates via the ACME protocol (RFC 8555). Before Let's Encrypt (2014), only ~40% of pages used HTTPS; by 2026, over 90% do. ### HSTS (HTTP Strict Transport Security) HSTS (`Strict-Transport-Security` header) instructs browsers to only connect to a domain via HTTPS, refusing to downgrade to HTTP even if the user types `http://`. It also prevents users from clicking through certificate warnings. ``` Strict-Transport-Security: max-age=63072000; includeSubDomains; preload ``` - **max-age**: Duration in seconds (2 years = 63,072,000) - **includeSubDomains**: Apply to all subdomains - **preload**: Eligible for browser HSTS preload lists (hardcoded in Chrome/Firefox) Domains on the preload list are never contacted over HTTP, even on first visit. google.com, paypal.com, and thousands of others are preloaded. ## Further Reading - [RFC 8446 — TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446): Current TLS standard (Rescorla, 2018) - [RFC 5246 — TLS 1.2](https://www.rfc-editor.org/rfc/rfc5246): Widely deployed TLS version - [Let's Encrypt Stats](https://letsencrypt.org/stats/): Certificate issuance data