HTTPS
Also known as: HTTP Secure, HTTP over TLS
The way web browsers and websites exchange pages with TLS protecting every message, so no one on the way can read or change them.
Draft - this entry has not been reviewed yet.
Formal
The web's request-and-answer protocol between a client and a server, carried inside a TLS connection, usually on port 443, so the pages, forms and cookies sent are encrypted and checked for changes.
In plain English
Like ordering from a shop by sealed, tamper-proof envelope instead of shouting your order and card number across the street.
In practice
When a customer pays at a small Danish web shop whose address starts with https://, the card number travels encrypted from the browser to the shop's payment page, and anyone on the café wifi sees only scrambled data.
Why it matters
Plain, unprotected web traffic can be read and changed by anyone along the route, so HTTPS is now the expected minimum for any website handling logins or personal data.
Technical deep dive
HTTPS began with Netscape's SSL in the mid-1990s and was first written up as RFC 2818, HTTP Over TLS (2000); its rules now live in RFC 9110, which defines the https URI scheme and how the client must check the server's identity against the certificate. A typical HTTP/1.1 or HTTP/2 exchange is: resolve the name, open TCP to port 443, run a TLS handshake in which the ClientHello carries the hostname in the Server Name Indication extension (RFC 6066) and the protocol choice in ALPN (RFC 7301, for example h2 or http/1.1), validate the certificate chain and the subjectAltName, and only then send the HTTP request inside TLS records. HTTP/3 (RFC 9114) runs over QUIC on UDP 443, where TLS 1.3 is integrated into the transport handshake (RFC 9001); clients discover it through the Alt-Svc header or the HTTPS DNS record (RFC 9460).
HTTPS encrypts the method, path, query string, headers, cookies and body, but not everything. The IP addresses, ports, timing and approximate sizes of messages stay visible, the DNS lookup leaks the name unless encrypted DNS is used, and the SNI field has traditionally been sent in clear text; Encrypted Client Hello, standardised as RFC 9849 in 2026, closes that gap where both browser and server support it. A valid certificate proves control of the domain, not honesty: phishing sites routinely obtain free domain-validated certificates through ACME (RFC 8555). Certificate Transparency logs let domain owners spot certificates issued for their names without their knowledge.
The weakest point is the transition from HTTP. If a user types a bare domain name, the first request may go out over plain HTTP, and an on-path attacker can keep the victim on HTTP while talking HTTPS to the real site (SSL stripping, demonstrated by Moxie Marlinspike in 2009). HTTP Strict Transport Security (RFC 6797) tells the browser to use only HTTPS for the domain for max-age seconds, optionally including subdomains, and the browser preload list removes even the first insecure request. Session cookies also need the Secure attribute, or they can leak over an HTTP request to the same host. Browsers block most mixed content and label HTTP pages "Not secure"; Chrome replaced the padlock with a neutral icon in 2023 precisely because users read it as a sign that a site is trustworthy.
In real deployments HTTPS often ends before the application does. CDNs and load balancers terminate TLS, and the hop to the origin server is only protected if it is re-encrypted; corporate TLS-inspection proxies deliberately break end-to-end encryption by installing their own root CA on managed devices. Operational checks therefore cover the whole chain: HTTP-to-HTTPS redirects and HSTS, disabled legacy protocol versions, certificate inventory and automated renewal (public certificate lifetimes are being cut in steps, to 200 days from March 2026), and encryption between internal tiers.
What to learn first
Everything this builds on, foundations first.
Relationships
- A kind of
- Protocol
- Implements
- Confidentiality
Sources & further reading
Standards & official texts
- RFC 9110 - HTTP Semantics
- RFC 9849 - TLS Encrypted Client Hello · IETF
Textbooks
- Kurose & Ross, Computer Networking: A Top-Down Approach
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Mentioned in
Check yourself
Loading…