Understanding TLS/HTTPS

HTTPS is not a separate protocol — it is HTTP carried over TLS (Transport Layer Security). The browser and server first establish a TLS session, creating an encrypted tunnel, and then exchange ordinary HTTP requests and responses inside it. That's why on an https:// connection the whole exchange — URL path, headers, and body — is encrypted on the wire, so an attacker in the middle can neither read nor tamper with it.

The three guarantees TLS provides

TLS delivers three security properties at once. Confidentiality hides the traffic with symmetric encryption; integrity detects tampering in transit via AEAD (e.g., AES-GCM, ChaCha20-Poly1305) or a MAC; and authentication uses a certificate to prove the peer really owns the domain you think you're talking to. Confidentiality without authentication is a trap: the data is encrypted, but you don't know *who* you're securely talking to, leaving you fully exposed to a man-in-the-middle.

The handshake: full TLS 1.2 flow

A classic TLS 1.2 handshake takes several round trips. The client sends a ClientHello advertising its supported TLS versions, cipher suite list, and a random value; the server answers with a ServerHello naming the chosen parameters plus its Certificate. They then exchange key-exchange parameters, both sides derive the same symmetric session key, and a Finished message locks the handshake in.

Client                                    Server
  |  ClientHello (versions, ciphers, rand)   |
  | ---------------------------------------> |
  |  ServerHello (chosen cipher, rand)        |
  |  Certificate (server cert chain)          |
  |  ServerKeyExchange (ECDHE params)         |
  |  ServerHelloDone                          |
  | <--------------------------------------- |
  |  ClientKeyExchange (ECDHE pubkey)         |
  |  ChangeCipherSpec / Finished              |
  | ---------------------------------------> |
  |  ChangeCipherSpec / Finished              |
  | <--------------------------------------- |
  |  ==== encrypted application data ====     |

The crucial step is the key exchange. Modern deployments almost always use ECDHE (elliptic-curve Diffie-Hellman, ephemeral). A fresh temporary key pair per session derives the session key, so even if the server's private key later leaks, previously recorded traffic can't be decrypted. This property is called forward secrecy, a major advantage that old static-RSA key exchange lacked.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446) dramatically simplified and sped up the handshake while removing weak legacy algorithms.

Speed: 1.2 typically needs 2-RTT, but 1.3 cuts it to 1-RTT, and on resumption it can use 0-RTT to send application data in the very first flight.
Safe by default: 1.3 removed static RSA key exchange (no forward secrecy) and weak ciphers (RC4, 3DES, CBC modes). Every remaining cipher suite is AEAD.
More is encrypted: 1.3 encrypts most handshake messages after ServerHello, including the certificate, so observers see less.
The 0-RTT catch: 0-RTT early data can be vulnerable to replay, so restrict it to idempotent, safe requests like GET.

Certificates and CAs

A server certificate is a document in which a Certificate Authority (CA) vouches, with its signature, that 'this public key belongs to this domain.' The browser walks the certificate chain the server sends until it reaches a root CA it trusts, then checks that the domain name (and SANs) match, that the validity period hasn't expired, and that it hasn't been revoked. Free CAs like Let's Encrypt, together with ACME automation, mean issuance and renewal are largely automatic today.

SNI and ALPN

Because one IP now hosts many domains, the server needs to know which domain's certificate the client wants. SNI (Server Name Indication) solves this by carrying the target hostname in the ClientHello. SNI is sent in the clear, though, exposing the hostname to observers; the follow-up standard that hides it is ECH (Encrypted Client Hello). Separately, ALPN (Application-Layer Protocol Negotiation) agrees on the application protocol to use next (h2, http/1.1, …) within the same handshake, so the connection can jump straight to HTTP/2 with no extra round trip.

Cipher suites and mixed content

A cipher suite bundles the key exchange, authentication, symmetric cipher, and hash algorithms (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256). Servers should be configured to prefer only strong suites. Finally, a common real-world snag is mixed content: when an HTTPS page loads images or scripts over http://, browsers block or warn. Active mixed content like scripts can undermine the whole page's security and is always blocked. The fix is to serve every subresource over https:// (use explicit https rather than relying on protocol-relative URLs).