Deprecating Powerful Features on Insecure Origins(Chrome –unsafe)

by tabtuon Posted on

–unsafely-treat-insecure-origin-as-secure=”http://localhost:8080″

We (Chrome Security) originally sent this out to various browser development mailing lists. See the original intent-to-deprecate email on blink-dev. This is based on the original idea to prefer secure origins for powerful new features.
This is a living document — as we learn more, we’ll update this page.

Proposal

We want to start applying the concepts in Secure Contexts to features that have already shipped and which do not meet the (new, not present at the time) requirements. In particular, this approximately requires that powerful features only be accessible on “secure origins” (such as HTTPS) where the full ancestor chain is also secure.
We want to start by requiring secure origins for these existing features:
As with gradually marking HTTP as non-secure, we expect to gradually migrate these features to secure-only, based on thresholds of usage, starting with lowest usage and moving towards higher. We also expect to gradually indicate in the UX that the features are deprecated for non-secure origins.
The deprecation strategy for each of these features is not decided on and may very well differ from feature to feature. We don’t currently know what the thresholds will be, or how heavily used the features are on what kinds of origins. We are in the process of gathering data, and will report back when we have it. There are no firm plans at all at this time, other than eventual deprecation. We intend for this to stimulate a public discussion of the best way to approach this deprecation. So, to that point, we’d love to hear what the community thinks.

Testing Powerful Features

If you are a developer that needs to keep testing a site using a Powerful Feature but you only have a non-secure test server, you have several options:
  1. Secure the server with a publicly-trusted certificate. If the server is reachable from the Internet, several public CAs offer free, automatically-renewed server certificates.
  2. http://localhost is treated as a secure origin, so if you’re able to run your server from localhost, you should be able to test the feature on that server.
  3. You can run chrome with the –unsafely-treat-insecure-origin-as-secure=”http://example.com” flag (replacing “example.com” with the origin you actually want to test), which will treat that origin as secure for this session. Note that on Android and ChromeOS this requires having a device with root access/dev mode. (This flag is broken in Chrome 63 but fixed in Chrome 64 and later. Prior to Chrome 62, you must also include the –user-data-dir=/test/only/profile/dir to create a fresh testing profile for the flag to work.)
  4. Create a self-signed certificate for temporary testing. Direct use of such a certificate requires clicking through an invalid certificate interstitial, which is otherwise not recommended. Note that because of this interstitial click-through (which also prevents HTTPS-response caching), we recommend options (1) and (2) instead, but they are difficult to do on mobile. See this post on setting up a self-signed certificate for a server for more information on how to do this.An alternative approach is to generate a self-signed root certificate which you place into the trust store of the developer PC/devices, and then issue one or more certificates for the test servers. Trusting the root certificate means that Chrome will treat the site as secure and load it without interstitials or impacting caching.
We continue to invest in improved methods for testing powerful features on insecure origins, and we’ll update this page once we’ve developed them. Feel free to contribute ideas to security-dev@chromium.org.

Relevant Bugs

Post author

Written by

Leave a Comment