While I’m a firm believer that every site should be using HTTPS, sadly, not every site is yet doing so. Looking at Chrome data, today around 92% of navigations are HTTPS:

…and the pages loaded account for around 95% of browsing time:

Browsers are working hard to get these numbers up, by locking down non-secure HTTP permissions, blocking mixed content downloads, and by attempting to get the user to a secure version of a site if possible (upgrading mixed content, and upgrading navigations).

Chrome and Edge have adopted different strategies for navigation upgrades:

Chrome

In Chrome, if you don’t type a protocol in the address bar, will try HTTPS first and if a response isn’t received in three seconds, it will race a HTTP request. There’s an option to require HTTPS:

When this option is set, attempting to navigate to a site that does not support HTTP results in a warning interstitial:

Edge

In Edge, we are experimenting with an “Automatic HTTPS” feature to upgrade navigations (even if http:// was specified) to use HTTPS.

The feature defaults to a list-based upgrade approach, whereby we deliver a component containing sites believed to be compatible with TLS. The list data is stored on disk, but is unfortunately not readily human-readable due to its encoding (for high-performance read operations):

Alternatively, if Always switch is specified, all requests are upgraded from HTTP to HTTPS unless:

• The URL’s hostname is dotless (e.g. http://intranet)
• The URL targets a non-default port (http://example.com:8080)
• The hostname is included on a hardcoded exemption list containing just a handful of HTTP-only hostnames that are used by features or users to authenticate to Captive Portal interceptors. kAutomaticHttpsNeverUpgradeList ={"http://msftconnecttest.com", "http://edge.microsoft.com", "http://neverssl.com"};
• The user has previously opted-out of HTTPS upgrade for the host by clicking the link on the connection failure error page.

Diagnostics

Beyond the browser-specific features, browsers might end up on a HTTPS site even when the user specified a http:// url because:

• The site is on the HSTS Preload list (including preloaded TLDs)
• The site was previously visited over HTTPS and returned a Strict-Transport-Security header to opt-in to HSTS
• The site was previously visited over HTTP and returned a cacheable HTTP/3xx redirect to the HTTPS page

In some cases, such upgrades might be unexpected or problematic, but figuring out the root cause might not be entirely trivial, particularly if an end-user is reporting the problem and you do not have access to their computer.

Local Diagnostics

You can use the Network tab of the F12 Developer Tools to see whether a cached redirect response is responsible for an HTTPS upgrade.

You can see whether Edge’s Automatic HTTPS feature upgraded a request to HTTPS by looking at the F12 Console tab:

To see if HSTS is responsible for an upgrade, on the impacted client, visit about://net-internals/#hsts and enter the domain in the box and click Query. Look at the upgrade_mode values:

If the static_upgrade_mode value shows FORCE_HTTPS, the site is included in the HSTS preload list. If FORCE_HTTPS is specified in dynamic_upgrade_mode, the site sent a Strict-Transport-Security opt-in header.

You can clear out dynamic_upgrade_mode entries by using the Cached images and files: All time option in the Clear Browsing Data dialog box:

Remote Diagnostics

If you don’t have direct access to the client, you can ask the user to collect a NetLog capture to analyze. The NetLog will show HTTPS upgrades from HSTS and from previously cached responses.

You can see a HSTS Upgrade by using the search box to look for either TRANSPORT_SECURITY_STATE_SHOULD_UPGRADE_TO_SSL (which will appear for all URLRequests with a true or false value) or for reason = "HSTS" which will find the internal redirect to upgrade to HTTPS:

Unfortunately, at the moment there’s no clear signal that a request was upgraded by Edge’s Automatic HTTPS feature, because the rewrite of the URL happens above the network stack.

Please help secure the web by moving all sites to HTTPS!

-Eric

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, presently working on Microsoft Edge. My words are my own. View more posts