This post has been republished via RSS; it originally appeared at: Microsoft Edge Blog.Starting with Microsoft Edge 92, users can preview the Automatic HTTPS feature, which automatically switch your connections to websites from HTTP to HTTPS. As you browse the web, you may notice that the Microsoft Edge address bar displays a “not secure” message for some sites, and a lock icon for others. These icons indicate whether a site is delivered over HTTP, or the more secure HTTPS protocol.
edge://flags/#edge-automatic-httpsin Edge 92 Canary/Dev and enable Automatic HTTPS
- Hit the “Restart” button that appears to restart Microsoft Edge.
edge://settings/privacyand turn on “Automatically switch to more secure connections with Automatic HTTPS”.
A broad scope of protectionAutomatic HTTPS applies to all user navigations. Whether you type a URL in the address bar or click on a link that takes you to a new site, the feature will check whether to switch your connection to HTTPS. It doesn’t matter how you browse—Automatic HTTPS will help keep you secure.
The known-capable domains listIn addition to security, we know that productivity and performance are top of mind for our users. When enabled, Automatic HTTPS defaults to upgrading navigations only on domains that are likely to support HTTPS. Scoping to HTTPS-capable domains reduces the likelihood of connection failures, as well as potential performance or reliability issues with “try HTTPS first and fall back to HTTP” approaches. The list of HTTPS-capable domains is delivered to the user’s device via a browser component, and is listed on
edge://components/. Microsoft generates the list based on top domains that receive a high rate of traffic delivered over HTTPS and are not configured to require HTTPS (i.e. are not already included in HSTS Preload Lists).
Reducing encountered errors with local cachingSome users may prefer that all navigations use HTTPS, and are okay with encountering error pages more frequently in exchange for heightened security. These resulting error pages will enable you to try the same URL delivered over HTTP instead: [caption id="attachment_24747" align="aligncenter" width="640"] An example of an error occurring on a site that is specially configured to force use of HTTP only.[/caption] Regardless of whether you have configured Automatic HTTPS to run on known-capable or all domains, the feature will locally cache recent domains that resulted in a navigation error. The next time you visit a cached site, Automatic HTTPS will skip the attempt to upgrade, avoiding duplicative error pages and keeping you focused on your browsing. Users can clear this cache by visiting edge://settings/privacy and clearing “Browsing history”. Any cache entries stored during an InPrivate session will automatically be cleared when leaving InPrivate.
Subresource upgradesHTTPS best protects you when all resources are delivered over HTTPS—not just the top-level document shown in the address bar. “Active” content subresources can access some or all of the content on the page you’re visiting. If these are delivered over HTTP, an attacker might still be able to manipulate content on the page. At the same time, switching these to HTTPS can potentially lead to other errors if delivery over HTTPS is not supported for a given subresource. When Automatic HTTPS is configured to switch to HTTPS only on known-capable domains, the feature will upgrade same-host active subresources to HTTPS, as these are more likely to also support HTTPS. For example, on http://contoso.com, http://contoso.com/script.js would be upgraded, but http://subdomain.contoso.com/script.js and http://microsoft.com/script.js would not. Active content subresources in scope of this feature include scripts, iframe sources, and fetch() requests; you can find a longer list on MDN. The “always switch” setting once again is designed for heightened security: all active content subresources will be upgraded. Failures to load subresources (and thus some site breakage) may be more common.
Developer guidanceWe recommend that website owners serve all content over HTTPS, including top-level documents and any subresources. Developers should also consider configuring their websites to require HTTPS, though that may not be feasible for all domains. If you have not configured your domain in this way, you can observe the effects of Automatic HTTPS on your own website. Hit F12 to pull up the DevTools, then bring up the Console tab. Under “Console settings”, enable “Preserve log”: Then visit your site using the http:// scheme (e.g. http://example.com). If Automatic HTTPS switched your connection to HTTPS, a message will appear in the console: The exact message that appears depends on whether any subresources were upgraded:
|The document switched to HTTPS, but no subresources were upgraded||Automatic HTTPS switched your connection to HTTPS.”|
|The document switched to HTTPS, and same-host active subresources were upgraded because Automatic HTTPS is set to “upgrade on websites likely to support HTTPS”||Automatic HTTPS switched your connection and same-host subresources to HTTPS.”|
|The document switched to HTTPS, and all active subresources were upgraded because Automatic HTTPS is set to “always switch”||Automatic HTTPS switched your connection and subresources to HTTPS.”|