Cloud Parts

HTTPS

HTTP inside TLS: the same requests and responses, sent only after the client has checked the server’s certificate, and encrypted and integrity-protected all the way, on port 443 by default.

What it is
Network protocols (web protocols)
Part of
Built on HTTP
Type
Open source
Made by
IETF
License
Open standard (IETF RFC)
Facts checked
8 October 2026
Website

What it is

An https URL names a server that listens for TCP connections, on port 443 unless the URL says otherwise, and can set up a TLS connection secured for HTTP. The client connects, runs the TLS handshake first, and only then sends HTTP requests as TLS application data; with HTTP/3 the same URL is reached over QUIC on UDP. Before trusting the connection the client must check that the server’s certificate matches the host in the URL, by DNS name or IP address, using its set of trusted certificate authorities. If it doesn’t, a browser must stop or ask the user, and an automated client should stop. Every byte after the handshake is encrypted and protected against tampering, so people on the path see the server’s address and name but not the URLs, headers, cookies or bodies.

HTTPS isn’t a different protocol from HTTP, just HTTP on a secured connection, but https://shop.example and http://shop.example are different origins with separate namespaces. A site can make browsers stick to HTTPS with HTTP Strict Transport Security: a Strict-Transport-Security response header (for example max-age=31536000; includeSubDomains) tells the browser to rewrite every future http link to that host as https for that many seconds and to refuse the connection on any certificate error, with no click-through. The first visit is still exposed, which browsers close with preloaded lists of HSTS hosts. HTTPS was first documented in RFC 2818 (2000) and has been defined in the core HTTP specification, RFC 9110, since 2022.

Why teams pick it

  • Confidentiality and integrity for everything above TLS: paths, query strings, headers, cookies and bodies
  • The client knows it reached the server named in the URL, not an impostor on the network or behind poisoned DNS
  • Required in practice for modern HTTP: HTTP/2 is negotiated as h2 inside TLS, and HTTP/3 only serves https origins directly
  • HSTS lets a site stop browsers from ever falling back to plain HTTP or clicking through certificate warnings

Watch out for

  • Certificates expire and must match every host name served; a lapsed or mis-issued certificate breaks the site for every verifying client
  • Encryption ends wherever TLS terminates: a CDN, load balancer or proxy that holds the certificate sees the plaintext
  • The server’s IP address and, in the unencrypted ClientHello, its name are still visible to observers
  • HSTS can’t protect the very first request to a site unless the host is on a browser’s preload list

How it fits with other technologies

See a site redirect to HTTPS and pin itself there with HSTS · bash

curl -sI http://github.com | grep -i '^location'
# Location: https://github.com/

curl -sI https://github.com | grep -i strict-transport
# strict-transport-security: max-age=31536000; includeSubdomains; preload

# HTTP version negotiated over TLS, and the certificate check result (0 = verified)
curl -sI https://example.com -o /dev/null -w '%{http_version} %{ssl_verify_result}\n'
# 2 0

See it in a real stack

No architecture uses HTTPS yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1996–2022

HTTP was originally used in the clear, but as it was used more and more for sensitive applications it needed security. Netscape’s Secure Sockets Layer, and then the IETF’s TLS, gave a way to secure any stream, and the practice that grew up was to run HTTP over SSL on its own port, because a TLS server expects a ClientHello as its first bytes while an HTTP server expects a request line. Eric Rescorla’s RFC 2818 (May 2000) wrote that practice down: use HTTP over TLS exactly as over TCP, on port 443, and check the server’s identity against the host in the URL.

Encryption on request wasn’t enough. Browsers let users click through certificate warnings, and a first request typed as http could be intercepted before any redirect, leaking session cookies. HTTP Strict Transport Security (RFC 6797, November 2012) let a site declare itself HTTPS-only so that browsers upgrade every request and fail hard on certificate errors. In June 2022 RFC 9110 brought the https scheme into the core HTTP specification, obsoleting RFC 2818, and HTTP/3 made https origins reachable over QUIC as well.

Why it’s built this way

A separate port and URL scheme
Since the first bytes of TLS and of HTTP differ, the simplest way to tell them apart was a different port, 443, and a different scheme, https. A companion document, RFC 2817, specified upgrading to TLS on HTTP’s own port instead.
Authority comes from the certificate
An https URL’s authority is tied to holding a certificate the client trusts for that host, so a client must verify it before treating the server as the origin. That’s what stops an on-path attacker or a poisoned DNS answer from impersonating the site.
Let sites opt out of plain HTTP
Because HTTPS sat alongside HTTP rather than replacing it, users could still be sent to http or click past warnings. HSTS turns HTTPS into a per-site rule that the browser enforces.

Timeline

  1. 1996

    SSL 3.0, the protocol HTTPS first ran over in practice

  2. 2000

    RFC 2818 documents HTTP over TLS on port 443

  3. 2012

    HTTP Strict Transport Security published as RFC 6797

  4. 2015

    HTTP/2 negotiated as h2 within TLS (RFC 7540)

  5. 2022

    RFC 9110 defines https in core HTTP; HTTP/3 brings it to QUIC

Sources7 · facts checked 8 October 2026

Improve this page on GitHub