How Safari Automatically Upgrades HTTP Requests to HTTPS

This article explains the technical mechanisms the Safari web browser uses to automatically upgrade insecure HTTP navigation requests to secure HTTPS connections. By leveraging a combination of local preload lists, HTTP Strict Transport Security (HSTS) policies, DNS HTTPS resource records, and optimistic connection upgrading with fallback capabilities, Safari protects user privacy and prevents unencrypted data transmission whenever a destination website supports encryption.

Local Lists and HSTS Preloading

Before sending any request over the network, Safari checks the destination domain against locally stored databases. Safari includes a built-in list of known HTTPS-supporting domains, which incorporates the standard HTTP Strict Transport Security (HSTS) preload list. Additionally, if you have visited the website previously and the server responded with an HSTS header, Safari caches that directive. If the domain matches either the built-in list or the local HSTS cache, Safari internally rewrites the http:// request to https:// before any network traffic leaves the device.

DNS HTTPS Resource Records

When a domain is not found in the local cache, Safari utilizes the Domain Name System (DNS) to determine if an upgrade is possible. Alongside standard requests for IP addresses (A and AAAA records), Safari queries the DNS server for Type 65 (HTTPS) resource records. If the website administrator has configured this record, the DNS response explicitly informs Safari that the server supports HTTPS. Upon receiving this record, Safari automatically upgrades the navigation request to use a secure connection before initiating the initial network handshake.

Optimistic Upgrading

If a website is not on a local list and does not provide a DNS HTTPS record, Safari employs an optimistic upgrade strategy, often referred to as Automatic HTTPS. Instead of connecting over the requested insecure port 80, Safari intercepts the navigation request and attempts to establish a secure TLS connection over port 443. This happens transparently in the background, assuming by default that most modern web servers are configured to handle HTTPS traffic.

Automatic Fallback to HTTP

Not all websites support encryption, so Safari includes a rapid fallback mechanism to prevent broken pages during an optimistic upgrade. When Safari attempts an unprompted HTTPS connection, it sets a strict timeout and monitors the handshake. If the server refuses the connection, fails the TLS handshake, presents an invalid certificate, or simply takes too long to respond, Safari immediately cancels the HTTPS attempt. The browser then seamlessly falls back to the original unencrypted HTTP request over port 80, allowing the legacy webpage to load normally.