Google has implemented a substantial improvement in Chrome’s online security by automatically converting insecure HTTP requests into HTTPS requests for all users. This functionality, known as HTTPS-Upgrades, aims to enhance the security of older links that originally used HTTP by initially trying to establish a connection via the encrypted HTTPS protocol.
While a limited introduction of this feature in Google Chrome commenced in July, as of October 16th, Google has now fully implemented it for all users on the Stable channel. An update from Google’s Engineering Program Management Leader, Chris Thompson, states, “We have enabled HTTPS-Upgrades by default on the trunk as of last week and are currently extending it to 100% of Stable users.”
What is the purpose of HTTPS-Upgrades in Google Chrome?
HTTPS-Upgrades is a Google Chrome feature designed to automatically elevate all primary navigations to HTTPS, which is the secure version of the HyperText Transfer Protocol, while providing a swift fallback to HTTP when necessary.
Traditionally, web browsers frequently initiated insecure HTTP requests to websites that were actually capable of supporting the more secure HTTPS. This could occur for various reasons, such as users clicking on outdated links or because the content on websites had not been updated to utilize the new protocol. Connections established via the HTTP protocol lack encryption, making them susceptible to eavesdropping, potentially resulting in the theft of sensitive data or credentials. Google has identified scenarios in which this insecurity could arise, including when a user accesses a site using HTTP Strict Transport Security (HSTS) for the first time, visits a site that defaults to HTTPS but does not employ HSTS, or navigates to a site that supports both HTTPS and HTTP without automatic redirection to HTTPS. The HSTS informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.
If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types http://www.foo.com/ or even just foo.com. This creates an opportunity for a man-in-the-middle attack. The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.
The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.
In all these cases, users’ privacy and security are put at risk through avoidable insecure connections, a problem that could affect a wide range of requests based on various configurations.
Existing methods for enforcing HTTPS, such as the HSTS preload list or manually curated upgrade lists, have their limitations. They often involve intricate and risky configurations or cater to only a select group of websites. Moreover, keeping an updated list of HTTPS-supported sites can be a challenging and resource-intensive task, frequently resulting in outdated information reaching users.
Google is addressing security concerns through HTTPS-Upgrades
This update in Chrome aims to automatically convert in-page HTTP links to HTTPS and includes a quick fallback option to HTTP if necessary. Additionally, the browser may respect an opt-out header, allowing web servers serving different content on HTTP and HTTPS to prevent automatic upgrades.
These changes will require adjustments to the Fetch specification, primarily concerning the upgrade of main-frame navigation requests and how network errors are handled in upgraded requests.
The impact of this upgrade is seen in several aspects of browsing:
- It’s limited to main-frame navigations, with existing mixed content policies governing subresource upgrades.
- Navigations initiated via the URL bar or JavaScript are eligible for these upgrades.
- The upgrade only affects idempotent requests like GET, aligning with the current mixed content policies for forms on upgraded pages.
- Even redirects from HTTPS to HTTP during initial navigations are upgraded.
While this automatic upgrade doesn’t completely prevent downgrades, it still provides a level of security equivalent to the existing standards. It reduces exposure to passive attackers, although active attackers could potentially interfere with the upgrade process. Importantly, this change might decrease developers’ incentives to fix HTTP references.
In light of the prevailing trend of marking HTTP pages as “Not secure,” this upgrade serves as a proactive measure to safeguard users, especially on websites that are unlikely to transition to HTTPS.
Security and Privacy Considerations
Automatic upgrade is not intended to prevent downgrades. If a site falls back to HTTP, users will be no worse off than in the status quo.
An active attacker could prevent a link from getting upgraded. This is no worse off than the status quo, where the link would be accessed over HTTP with no attempt to load it over HTTPS. This change does limit information observable to a purely passive attacker.
Silently upgrading HTTP URLs could have negative effects on the ecosystem by removing the incentive for developers to fix HTTP references, or making it less likely that they are aware of them at all. However, with many browsers already aggressively marking HTTP pages as “Not secure”, it is unclear what additional incentives could be used to get developers to fix HTTP links that could be HTTPS. Further, many such websites might be unmaintained or infrequently updated. By attempting to upgrade navigations to HTTPS, browsers protect users’ privacy on websites that wouldn’t ever get updated to point to HTTPS directly.
Risk
When numerous websites provide distinct content on their HTTPS and HTTP versions, automatically upgrading links can potentially complicate a user’s access to the “intended” page content. A prior study from 2020 approximated that around 1-3% of websites have at least one page that exhibits differences between their HTTP and HTTPS versions. However, it remains uncertain how this statistic corresponds to the overall percentage of page loads or how it directly affects the user experience.
Evaluating content equivalence proves to be a challenging task. Browsers will have to depend on feedback gathered through experimentation to assess the impact of unintended upgrades. Site administrators have the option to utilize the opt-out header to prevent these unwanted link upgrades.
Sources:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
https://github.com/dadrian/https-upgrade/blob/main/explainer.md
