HTTP over a protected channel
HTTPS is HTTP carried through a channel protected by TLS. The https URI scheme tells a client to establish transport protection before sending an HTTP message. The default port for HTTP over TLS is 443.
HTTP methods, status codes, and field semantics remain unchanged. TLS changes message transport between endpoints rather than web-resource semantics.
Protection scope
After TLS establishment, the request line, HTTP fields, request and response content, and application files are encrypted. Integrity protection detects modification in transit.
HTTPS does not hide all metadata. IP addresses, packet size and timing, and information required during connection establishment can remain visible. Channel protection does not remove application vulnerabilities after decryption.
Server-certificate validation
A client validates a signature chain to a trusted authority, the validity interval, permitted key usage, and the server name. DNS identifiers are carried in Subject Alternative Name.
A valid signature is insufficient when the certificate names another service. Manually accepting a warning removes active-intermediary protection. A server sends its end-entity certificate and required intermediate certificates, while the root is normally held by the client.
HTTPS redirects and HSTS
An HTTP redirect to HTTPS changes the target URI, but the first HTTP request remains unprotected. An on-path attacker can alter the redirect or keep the user on HTTP.
records the HTTPS requirement for the max-age interval. includeSubDomains extends the policy to subdomains. Preloading can protect an initial visit but requires careful domain management and compliance with browser-program rules.
Mixed content and secure cookies
Mixed content occurs when an HTTPS document retrieves scripts, style sheets, images, or other data through HTTP. An active HTTP resource can change the behavior of the complete page. Browsers block high-risk categories or attempt an HTTPS upgrade.
The Secure attribute restricts cookie transmission to protected transport. HttpOnly blocks JavaScript access, and SameSite limits selected cross-site requests. These controls are distinct and do not replace HTTPS.
TLS termination at an intermediary
TLS can terminate at a reverse proxy, load balancer, or CDN gateway. The path from that intermediary to the application becomes a separate connection and requires protection appropriate to the trust boundary.
An application often receives the original scheme and client address in fields added by a trusted proxy. Without a trusted-proxy list, an attacker can supply those fields and influence redirects, logs, or security rules.
HTTP/2, HTTP/3, and ALPN
Browsers normally use HTTP/2 through TLS. ALPN negotiates the application protocol during the TLS handshake without an additional exchange after connection establishment.
HTTP/3 uses QUIC over UDP. QUIC integrates TLS 1.3 handshake mechanisms without creating a conventional TLS-over-TCP stack. Cryptographic protection covers HTTP/3 data and much of QUIC control information.
HTTPS deployment checks
- The certificate covers every service name and includes required intermediates.
- HTTP redirects to a canonical HTTPS URI without loops.
- HSTS is enabled after checking every affected subdomain.
- The page loads no active resources through HTTP.
- Session cookies use Secure and other attributes appropriate to their purpose.
- Proxies and applications determine the original request scheme correctly.
- Certificate expiry and handshake failures are monitored.
Limits of HTTPS responsibility
HTTPS authenticates an endpoint according to its certificate and protects transmission. It does not establish that published information is true, prevent authorization errors, or protect data stored by the server. Record, key, and handshake details belong to TLS.