What actually happens between typing a URL and seeing the padlock
HTTP, the protocol underlying the web, was designed in 1991 with no thought given to privacy or authenticity — every request and response travels in plain text, readable by anyone positioned between your device and the server: your ISP, a coffee-shop Wi-Fi eavesdropper, or anyone running the router in between. HTTPS fixes this by running ordinary HTTP inside an encrypted, authenticated tunnel provided by TLS (Transport Layer Security). The web page content and the interaction with it are unchanged; what wraps around it is not.
SSL (Secure Sockets Layer) was Netscape's original encryption protocol from the mid-1990s. Every version of SSL is now considered insecure and has been formally deprecated — SSL 3.0 was retired in 2015. TLS is its successor and the standard in use today; "SSL" persists mostly as a legacy label in product names, certificate terminology, and casual conversation, even though the underlying protocol has been TLS for over two decades. HTTPS is simply "HTTP over TLS" — the combination of the familiar web protocol with a TLS-encrypted transport underneath it, conventionally served on port 443 instead of HTTP's port 80.
| Version | Released | Status |
|---|---|---|
| SSL 2.0 / 3.0 | 1995 / 1996 | Deprecated — insecure, must not be used |
| TLS 1.0 / 1.1 | 1999 / 2006 | Deprecated — disabled by all major browsers since 2020 |
| TLS 1.2 | 2008 | Widely supported, still secure when configured correctly |
| TLS 1.3 | 2018 | Current standard — faster handshake, older weak options removed entirely |
TLS gives a connection three distinct guarantees, and it's worth separating them because they solve different problems:
Confidentiality. Data is encrypted so that anyone intercepting it in transit sees only unreadable ciphertext, not the actual request or response content.
Integrity. Every message includes a cryptographic authentication check, so any tampering with the data in transit — even flipping a single bit — is detected and the connection is aborted rather than silently accepting altered data.
Authentication. A digital certificate proves the server is actually who it claims to be, preventing an attacker from simply impersonating yourbank.com and intercepting traffic meant for it. This is the piece that depends on the certificate authority system described below.
TLS relies on asymmetric (public-key) cryptography, which uses a mathematically linked pair of keys: a public key, freely shared with anyone, and a private key, kept secret by its owner. Data encrypted with the public key can only be decrypted with the matching private key, and a message signed with the private key can be verified by anyone holding the public key — proving it came from whoever holds the private key, without that private key ever needing to be shared or transmitted.
This solves a problem that plain symmetric encryption (the same key used to both encrypt and decrypt) can't: two parties who have never met can still establish trust and a shared secret over a connection an attacker might be actively watching. In practice, TLS uses asymmetric cryptography only briefly, at the start of the connection, to safely agree on a shared symmetric key — asymmetric algorithms are computationally expensive, while symmetric encryption (such as AES) is fast enough to handle a stream of ordinary web traffic.
A public key on its own proves nothing — anyone can generate a key pair and claim to be anyone. A digital certificate solves this by binding a public key to a domain name, digitally signed by a trusted third party called a Certificate Authority (CA). Your browser and operating system ship with a built-in list of CAs they trust; when a server presents a certificate signed by one of those CAs, the browser accepts the identity claim.
Certificates form a chain of trust: a server's certificate is typically signed by an intermediate CA certificate, which is in turn signed by a root CA certificate that's built directly into your browser or OS trust store. Verifying a certificate means walking this chain back to a trusted root.
| Certificate type | What's verified | Typical use |
|---|---|---|
| Domain Validated (DV) | Control of the domain only | Most websites; issued automatically, often free (e.g. Let's Encrypt) |
| Organization Validated (OV) | Domain control plus verified organisation identity | Business and corporate sites |
| Extended Validation (EV) | Rigorous legal and operational identity checks | Banking and high-assurance sites; historically shown with a green browser bar |
Let's Encrypt, launched in 2016, dramatically changed this landscape by issuing free, automatable domain-validated certificates, which is a major reason HTTPS adoption across the web went from a minority of sites to the overwhelming majority within a few years. You can restrict which CAs are even allowed to issue a certificate for your domain using a DNS CAA record — covered in our guide to DNS records.
Before any encrypted application data flows, the client and server perform a handshake to agree on encryption parameters, verify identity, and establish a shared secret. The process differs meaningfully between TLS versions.
Client → Server : ClientHello (supported TLS versions, cipher suites, random value) Server → Client : ServerHello (chosen cipher suite, random value) Server → Client : Certificate (server's public key certificate) Server → Client : ServerHelloDone Client → Server : Key exchange material (encrypted with server's public key) Client → Server : ChangeCipherSpec, Finished Server → Client : ChangeCipherSpec, Finished [ Encrypted application data now flows both directions ]
This typically takes two full round trips between client and server before any actual page data can be sent — a meaningful source of latency, especially on high-latency mobile connections.
TLS 1.3, standardised in 2018, redesigned the handshake to complete in a single round trip in the common case, and it removed support for older, weaker cryptographic options entirely rather than merely discouraging them — there is no way to negotiate down to a broken cipher, because none are offered. It also introduced 0-RTT (zero round-trip time) resumption, letting a returning client send encrypted application data in its very first message when reconnecting to a server it has already established a session with, at the cost of some subtle replay-attack considerations that server implementations have to guard against.
TLS_AES_256_GCM_SHA384). Modern TLS 1.3 deployments favour forward secrecy, achieved through ephemeral Diffie-Hellman key exchange, meaning each session uses a temporary key that's discarded afterward — so even if a server's long-term private key is later compromised, past recorded traffic still can't be decrypted.If any step fails, the browser shows a prominent warning rather than silently proceeding — the assumption is that a broken certificate is more likely to indicate an attack in progress than a harmless misconfiguration, so browsers deliberately make it inconvenient to click through.
Even with HTTPS available, a user typing a bare domain name or clicking an old link may initially connect over plain HTTP, creating a brief window for an attacker to intercept that first request and strip away the upgrade to HTTPS — an attack known as SSL stripping. HSTS (HTTP Strict Transport Security) closes this gap: a server sends a response header telling the browser to only ever connect to that domain over HTTPS for a specified period, entirely skipping the vulnerable plain-HTTP request on every subsequent visit.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The preload directive allows a site to be baked directly into browsers' shipped HSTS lists, so that even a user's very first-ever connection to the domain is protected, closing the gap left by the "first visit" problem entirely.
It's worth being precise about the limits. TLS protects data in transit between client and server — it says nothing about what happens to that data once it arrives. A phishing site can have a perfectly valid HTTPS certificate for its own (deceptively named) domain; the padlock icon confirms you're talking securely to whoever controls that domain, not that the domain itself is trustworthy or legitimate. TLS also doesn't protect against malware on either endpoint, weak passwords, or vulnerabilities in the application logic running on top of the secured connection.
Most browsers let you view certificate details by clicking the padlock icon, but the command line gives a fuller picture:
openssl s_client -connect example.com:443 -servername example.com openssl x509 -in cert.pem -text -noout
The first command opens a raw TLS connection and dumps the negotiated protocol version, cipher suite, and full certificate chain — useful for diagnosing misconfigurations or simply seeing exactly what a server actually offers.
Further reading: RFC 8446 (TLS 1.3), RFC 5280 (X.509 certificates), RFC 6797 (HSTS).