HTTPS — Glossary

HTTPS, short for Hypertext Transfer Protocol Secure, is HTTP sent through a TLS connection so the server is authenticated and the traffic is private and tamper-evident. The https URI scheme is defined in RFC 9110, section 4.2.2, and uses TCP port 443 by default. The older RFC 2818 described the same idea and is obsoleted by RFC 9110.

How it works

HTTPS adds no new HTTP syntax. The requests and responses are the ones described under HTTP. The change is the layer beneath them: the client opens a TCP connection to port 443, completes a TLS handshake, and only then sends HTTP messages inside encrypted records.

Authentication: the server presents a certificate. The client must check that it is valid for the host in the URL, matching a DNS name or IP address in the subjectAltName extension. RFC 9110 forbids falling back to the certificate's Common Name.
Confidentiality and integrity: after the handshake, request lines, headers, cookies and bodies are encrypted and cannot be altered undetected.
Separate origin: https://example.com and http://example.com are distinct origins with separate namespaces, even for the same host.
Protocol choice: HTTP/2 over TLS is negotiated during the handshake with the ALPN identifier h2.

The next run places a byte-recording relay between curl and a local HTTPS server, then checks which strings appeared on the wire. The request was for /account/secret-path?token=abc123 on the host app.example.test.

'app.example.test'           visible on the wire: True
'/account/secret-path'       visible on the wire: False
'token=abc123'               visible on the wire: False
'GET '                       visible on the wire: False
'secure hello'               visible on the wire: False

What port does HTTPS use?

HTTPS uses TCP port 443 by default, taken from the https scheme when a URL has no explicit port. Sending plain HTTP to a TLS port fails: curl printed curl: (52) Empty reply from server when given a plain http URL for a local port that only spoke TLS. HTTP/3 also runs over TLS 1.3 but uses UDP, on whatever port the server advertises.

What does HTTPS encrypt, and what can still be seen?

HTTPS encrypts the path, query string, headers, cookies, body and status code. The run above shows the path and token never appear in the captured bytes.

Observers can still see the destination IP address, the port, the amount and timing of traffic, and usually the hostname. The hostname travels in the Server Name Indication field of the TLS ClientHello, which stays plaintext in TLS 1.3 even though the certificate is encrypted. Encrypted ClientHello, published as RFC 9849 in March 2026, exists to hide it where both sides support it. Plaintext DNS lookups can also reveal the name, as RFC 9849 itself notes.

Common pitfalls

Mixed content: an https page that loads a script over http is blocked. Browsers may auto-upgrade images, audio and video, and block the rest, so assets silently disappear until their URLs use https.
Disabling verification: flags such as curl -k or verify=False stop the check that makes HTTPS meaningful. RFC 9110 warns that ignoring the server's identity leaves the connection open to active attack. A self-signed certificate gives curl: (60) SSL certificate problem: self-signed certificate; trust the certificate instead.
Redirect-only upgrade: the first request to http:// is still plaintext and can be intercepted before the redirect. The Strict-Transport-Security header, defined in RFC 6797, tells browsers to use https for max-age seconds. Browsers ignore it if received over plain http.
Certificate and hostname mismatch: a certificate for example.com does not cover www.example.com or 192.0.2.1 unless listed. Check the subjectAltName entries, not the Common Name.

Related terms

HTTP — the protocol whose messages HTTPS carries
TLS — the handshake and encryption layer that makes HTTPS secure
DNS — name lookups that sit outside the HTTPS encryption
CORS — treats http and https versions of a site as different origins