HyperText Transfer Protocol Secure (HTTPS)

HTTPS (HyperText Transfer Protocol Secure) is HTTP layered over TLS (Transport Layer Security), providing encrypted and authenticated communication between clients and servers. HTTPS uses port 443 by default, compared to port 80 for plain HTTP. The protocol ensures data integrity, confidentiality, and server Authentication for every connection.

Usage

HTTPS protects three properties of communication:

• Confidentiality: TLS encryption prevents eavesdroppers from reading request and response data, including URL paths, query strings, Headers, request bodies, and Cookies
• Integrity: cryptographic message authentication detects tampering during transit, preventing silent modification of content by intermediaries
• Authentication: the server presents a certificate signed by a trusted certificate authority (CA), proving the client is communicating with the intended host

Without HTTPS, any device on the network path (routers, Wi-Fi access points, ISP equipment) has the ability to read, modify, or inject content into HTTP traffic. Common attacks on plain HTTP include credential theft, ad and tracking script injection, session cookie hijacking, and protocol downgrade to strip security headers.

HTTPS also preserves referral information. When a user navigates from an HTTPS page to another HTTPS page, the browser sends the full Referer header. When navigating from HTTPS to plain HTTP, browsers strip the referrer to the origin or omit the header entirely, causing analytics tools to report the visit as direct traffic. Operating on HTTPS retains referral data across the site and from other HTTPS sources.

HTTPS is the default protocol for the modern web. Browsers mark plain HTTP pages as insecure, search engines factor HTTPS into ranking signals, and features like service workers, geolocation, and Client Hints require a secure context.

TLS handshake

Each HTTPS connection begins with a TLS handshake to authenticate the server and establish an encrypted channel. The handshake in TLS 1.3 completes in a single round trip:

1. ClientHello: the client sends supported cipher suites, TLS version, and one or more ephemeral public key shares
2. ServerHello: the server selects a cipher suite, provides its own key share, and both sides derive the shared secret
3. Server certificate: the server sends its certificate chain (leaf, intermediate, root) and a digital signature proving possession of the private key
4. Finished: both sides exchange Finished messages to verify the handshake was not tampered with, and encrypted application data begins

In TLS 1.3, all handshake messages after ServerHello are encrypted. Earlier TLS versions required two round trips and sent more handshake data in plaintext.

Certificate chain

TLS authentication relies on a chain of trust linking the server's certificate to a trusted root:

• Root CA: a certificate authority whose self-signed certificate is pre-installed in browsers and operating systems. Root CAs serve as trust anchors.
• Intermediate CA: a certificate authority certified by the root CA. Intermediate CAs issue end-entity certificates on behalf of the root, adding a layer of protection. If an intermediate is compromised, the root CA revokes the intermediate without affecting other chains.
• Leaf certificate: the end-entity certificate presented by the server. The leaf contains the server's public key and the domain name(s) the certificate covers.

The browser verifies each link in the chain by checking digital signatures, validity periods, and revocation status. A missing or misordered intermediate certificate is one of the most common TLS configuration errors.

Certificate validation levels

Certificate authorities issue certificates at three validation levels:

• Domain Validation (DV): the CA verifies the applicant controls the domain. DV certificates are issued within minutes through automated challenges. Let's Encrypt issues DV certificates exclusively.
• Organization Validation (OV): the CA verifies the legal identity of the organization behind the domain. OV certificates display organization details in the certificate metadata.
• Extended Validation (EV): the CA performs the most thorough identity verification, including legal entity checks and physical address confirmation.

Certificates expire and must be renewed. Let's Encrypt certificates are valid for 90 days and are typically renewed automatically through the ACME protocol. Modern tooling handles issuance, renewal, and installation without manual intervention.

All three levels provide the same encryption strength. The difference is the degree of identity assurance. Browsers once displayed a green address bar for EV certificates, but Chrome removed this indicator in 2019 and other browsers followed. Modern browsers show a padlock icon for all valid certificates regardless of validation level. EV organization details are still accessible by inspecting the certificate.

Certificate Transparency

Certificate Transparency (CT) is a framework of public, append-only logs recording TLS certificates issued by participating certificate authorities. CT allows domain owners and researchers to monitor for misissued or unauthorized certificates.

When a CA issues a certificate, the CA submits the certificate to one or more CT logs and receives a Signed Certificate Timestamp (SCT). The SCT proves the certificate has been logged. Chromium-based browsers require SCTs for all publicly trusted certificates. A certificate without valid SCTs triggers a connection error.

Mixed content

An HTTPS page loading subresources over plain HTTP creates mixed content, undermining the security guarantees of the encrypted page.

Active mixed content includes scripts, stylesheets, iframes, and fetch() requests loaded over HTTP. Browsers block active mixed content entirely because a compromised script gains full control over the page.

Passive mixed content includes images, audio, and video loaded over HTTP. Browsers historically displayed these with a degraded security indicator. Modern browsers auto-upgrade passive mixed content requests to HTTPS and block the resource if HTTPS fails.

The Content-Security-Policy: upgrade-insecure-requests header or equivalent <meta> tag instructs the browser to rewrite all HTTP subresource requests to HTTPS before fetching them. This acts as a safety net during HTTP-to-HTTPS migrations where internal references still use http:// URLs in the source.

Content-Security-Policy: upgrade-insecure-requests

HSTS

HTTP Strict Transport Security complements HTTPS by instructing the browser to use HTTPS for all future connections to a host. Once the browser receives the Strict-Transport-Security header over HTTPS, the browser converts all http:// requests for the host to https:// before sending them. HSTS preloading embeds this policy in the browser itself, enforcing HTTPS from the first connection.

History and adoption

HTTPS was introduced in 1995 by Netscape Communications alongside SSL 2.0 in Netscape Navigator 1.1. The original specification layered HTTP over SSL, using a distinct port (443) and the https:// URI scheme.

SSL evolved through several versions. SSL 3.0 (1996) fixed critical flaws in SSL 2.0. TLS 1.0 (1999) succeeded SSL 3.0 with incremental improvements. TLS 1.1 (2006) and TLS 1.2 (2008) followed. TLS 1.3 (2018) removed legacy cryptographic algorithms, reduced the handshake to one round trip, and encrypted more of the handshake itself.

The formal specification for HTTPS, published in 2000, described how to layer HTTP over TLS, verify server identity, and handle URI differences from plain HTTP.

For most of the web's early history, HTTPS was reserved for payment processors and high-security applications because certificates required manual processes and carried significant cost. Let's Encrypt, launched in 2016, changed this by providing free, automated certificates through the ACME protocol. The availability of zero-cost certificates accelerated HTTPS adoption across the web.

Browser vendors further pushed adoption by making HTTPS the default. Chrome defaults to https:// for typed navigation, attempting a secure connection first and falling back to HTTP only when HTTPS fails. Roughly 95-99% of Chrome page loads now use HTTPS. Chrome is moving toward warning users before navigating to any public site over plain HTTP, completing the transition from HTTPS as optional to HTTPS as expected.

Example

A browser navigating to https://www.example.re establishes a TLS connection on port 443 before sending any HTTP data.

Request (sent over TLS)

GET /account HTTP/1.1
Host: www.example.re
Cookie: session=abc123

Response (sent over TLS)

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Strict-Transport-Security: max-age=31536000; includeSubDomains

The entire HTTP exchange (including the URL path /account, the session cookie, and the response body) is encrypted. A network observer sees the destination IP and (through SNI) the hostname www.example.re, but nothing else.

Takeaway

HTTPS layers HTTP over TLS to provide encrypted, authenticated communication. The TLS handshake verifies the server's identity through a certificate chain and establishes an encrypted channel in a single round trip. Certificate Transparency logs provide public accountability for certificate issuance. HSTS ensures browsers always use HTTPS for a given host. Mixed content policies prevent insecure subresources from undermining an encrypted page.

See also

• RFC 9110: HTTP Semantics, https URI Scheme
• RFC 2818: HTTP Over TLS
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9162: Certificate Transparency Version 2.0
• HTTP Strict Transport Security
• Strict-Transport-Security
• Cookies
• Redirects
• HTTP headers