When you visit a website and see a little padlock in your browser bar, that means the site is using HTTPS — the secure version of HTTP. HTTPS protects data in transit so attackers can’t eavesdrop, tamper with, or impersonate websites.
Behind that simple padlock is a carefully-designed system of networking and cryptography. Let’s walk through how it works step-by-step.
Before encryption happens, your browser and the server must first establish a basic network connection using TCP (Transmission Control Protocol).
This process is called the TCP three-way handshake:
SYN — The browser says “Hey server, can we talk?”
SYN-ACK — The server replies “Yes — ready to connect.”
ACK — The browser confirms and the connection opens.
At this point, the devices can communicate — but the data is still unencrypted. That’s where TLS comes in.
Once TCP is established, your browser initiates a TLS handshake (the security layer in HTTPS).
The server responds with its TLS certificate, which includes:
The server’s public key
The server’s domain name
Certificate authority (CA) signature
Expiration details
Your browser checks the certificate against:
The issuing Certificate Authority (e.g., Let’s Encrypt, DigiCert)
Whether the certificate is valid and not expired
Whether the certificate matches the domain name
Whether it has been revoked (via OCSP/CRL)
If verification fails, you see a security warning.
If it succeeds, the browser proceeds to key exchange.
Next, the browser and server establish shared encryption keys.
Modern HTTPS uses ephemeral key exchange (like ECDHE) to enable:
Perfect Forward Secrecy (PFS) — even if someone steals a server key later, past traffic remains secure
The process in simple terms:
Browser sends key-exchange parameters
Server sends its parameters + signs them with its private key
Both sides independently compute the same shared secret
From that shared secret, they derive:
Session encryption keys
Authentication keys
Now both sides have matching keys — without ever sending them directly.
Once the handshake completes, all communication is encrypted:
Requests you send (logins, forms, cookies)
Responses you receive (pages, data, API results)
HTTPS provides:
Confidentiality — outsiders can’t read the data
Integrity — data can’t be tampered with undetected
Authentication — you know you’re talking to the real server
Every message is encrypted and authenticated before transmission.
To avoid repeating full handshakes, TLS can resume sessions using:
Session tickets
Session IDs
This makes HTTPS faster on repeat connections.
Allows multiple HTTPS sites to share one IP address by sending the hostname during handshake.
Negotiates which HTTP protocol to use on top of TLS.
Forces browsers to always use HTTPS — preventing downgrade attacks.
HTTPS does not protect:
Data stored on the server
Malware on your device
Bad passwords or phishing
Content after it reaches its destination
It only protects data in transit.
HTTPS secures web traffic using a layered process:
TCP handshake — opens a network connection
Certificate verification — proves the server’s identity
Key exchange — securely creates shared encryption keys
Encrypted communication — protects data in transit
Enhancements — session resumption, SNI, ALPN, HSTS, PFS
The result is a web experience that is private, authenticated, and tamper-resistant — all behind that tiny padlock icon.