HTTP vs HTTPS: How TLS Actually Protects Your Traffic

HTTP is plaintext — anyone on the network path can read or tamper with the content. HTTPS wraps HTTP in TLS, which provides three guarantees: confidentiality through encryption, integrity through a message authentication code, and server identity through X.509 certificates. The TLS 1.2 handshake runs as four logical steps. Client sends ClientHello with its supported cipher suites and a random nonce. Server responds with ServerHello choosing one cipher suite, a server random, and its certificate. The client verifies the certificate chain — the server cert is signed by an intermediate CA, whose cert is signed by a root CA that the browser already trusts. Chain verification walks from the leaf up to a trusted root in the OS or browser trust store. If valid, the client generates a premaster secret, encrypts it with the server's public key from the cert, and sends it. Both sides now have the client random, server random, and premaster secret, which they mix through a KDF to produce the symmetric session key. From then on, application data is encrypted with AES-GCM or ChaCha20 using that key. The reason for the asymmetric-then-symmetric split: asymmetric operations are hundreds to thousands of times slower than symmetric ones, so we only use RSA or ECDHE to exchange one key, then use a symmetric cipher for actual bytes. TLS 1.3 made the handshake significantly better. It cut the handshake to 1-RTT by having the client speculatively send key material in its ClientHello, and supports 0-RTT for resumption (at a replay risk trade-off). It removed all weak ciphers — no more RC4, no MD5, no CBC mode with padding oracle risk. ECDHE is mandatory, so every session has Perfect Forward Secrecy — a compromised server private key cannot decrypt past captured traffic. All cipher modes are AEAD, so authentication and encryption are always combined.