Default to using https for requests from extensions, e.g. via CSP

Rob--W commented 2 years ago

Summary: To encourage the adoption of https in extensions, I propose to require https by default for requests made by extensions. The ability to make http:-requests can be offered as an opt-in, for those that really want to use http: instead of https:.

Background

Currently, sending a request to http and https is equally easy. Although developers may not notice any functional difference between using the http or https version of a website/API endpoint, users' privacy/security can be affected when their data is sent over insecure http:.

By requiring https: for requests from extensions by default, the connection over which user data is sent will be private/secure by default. When extension developers really need to send requests over insecure http:, they can opt out of the default policy.

Browsers have been defaulting to https for navigations for a while (e.g. since Firefox 91 in Private browsing mode and since Chrome 93), and over 80% worldwide (over 90% in the USA) of all page loads are over https, according to Let's Encrypt/Firefox telemetry. So for the majority of extensions, defaulting to http may be straightforward.

Proposal

The text above sketches the functional requirements. A way to implement this is through the Content Security Policy for extensions. Extensions have the ability to specify a custom content_security_policy in manifest.json. When they don't, a default CSP is applied. This proposal is about changing the value of this default CSP (not the minimum/base CSP that governs what the boundaries within which an extension has to operate).

The current default CSP (improved by #204) is simply:

script-src 'self'

To automatically replace http: with https:, the upgrade-insecure-requests CSP directive can be used:

script-src 'self'; upgrade-insecure-requests
- When an extension sends a request to http:, the browser will immediately redirect it to https. To help with debugging, Firefox shows the message "Content Security Policy: Upgrading insecure request ‘http://example.com/’ to use ‘https’". Chrome does not log anything, but the redirect is visible in the devtool's Network tab.

If more verbose reporting is desired, the default-src directive can be specified.

script-src 'self'; upgrade-insecure-requests; default-src 'self' https: wss: data: blob: moz-extension: 'unsafe-inline' (Firefox)
script-src 'self'; upgrade-insecure-requests; default-src 'self' https: wss: data: blob: filesystem: chrome-extension: 'unsafe-inline' (Chrome)
script-src 'self'; upgrade-insecure-requests; default-src 'self' https: wss: data: blob: safari-web-extension: 'unsafe-inline' (Safari)
- These policies are verbose because it is not possible to block one scheme; instead, the supported sources (and keywords) should be listed (minus what you want to block). There are some browser differences for supported web schemes, reflected above. 'unsafe-inline' is included to permit inline stylesheets (the script-src override already blocks inline scripts).
- When an extension sends a request to http:, the browser will still redirect to https:, and also log a CSP violation error to the console, and dispatch the securitypolicyviolation event.

The upgrade-insecure-requests keyword exists to allow devs to transition to https: without replacing "http:" with "https:" in their source code. If there is a desire to force extension developers to update their source code, then the above default-src policy can be used minus the upgrade-insecure-requests directive.

Browser-specific issue trackers

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1797086

xeenon commented 2 years ago

I support adding upgrade-insecure-requests. If we did the specific schemes version we would want to include wss: too. Wouldn't 'self' be enough for the extension scheme too?

ericjung commented 2 years ago

Long-term maintenance of SSL certificates on servers is burdensome. Smaller developers who maintain their own servers may stop the SSL renewal process over time. So, is there any recourse to accept expired certificates and allow the request to succeed? In such cases, the request/response is still encrypted.

Rob--W commented 2 years ago

I support adding upgrade-insecure-requests. If we did the specific schemes version we would want to include wss: too.

Thanks. wss: should definitely be included.

Wouldn't 'self' be enough for the extension scheme too?

That would not work, because it would prevent the embedding/load of resources from other extensions. E.g. a tab manager that shows images from another extension.

@ericjung Your comment expresses concerns about requiring https. Note that the proposal is about changing the default behavior. It is not constraining what extensions can do. If availability of https is a concern, an extension can opt out, as described in the first post.

Long-term maintenance of SSL certificates on servers is burdensome. Smaller developers who maintain their own servers may stop the SSL renewal process over time.

Let's Encrypt offers free certificates and tooling to automate renewal.

So, is there any recourse to accept expired certificates and allow the request to succeed? In such cases, the request/response is still encrypted.

This proposal does not prescribe ways to handle certificate validation. The default behavior of browsers apply, which includes (discouraged) mechanisms to ignore failed certificate validations.

ericjung commented 2 years ago

Let's Encrypt offers free certificates and tooling to automate renewal.

Indeed they do. I did not mention anything about cost so I’m not sure why you mention ‘free’. Cost is not a concern. The overhead to administer certificates, even with certbot, is non-trivial. That’s the concern.

The default behavior of browsers apply

Will the UI be surfaced so that users can choose to accept expired certificates?

hanguokai commented 2 years ago

Because it is a potential breaking change, as I mentioned in #298 , developers need to be adequately informed and given enough time to handle it.

carlosjeurissen commented 2 years ago

Sounds like a good move to make extensions safer by default. The concern of still wanting to use the non secure http protocol should be fixable by overwriting the default csp and not including the upgrade-insecure-requests right?

Agreed with @hanguokai, this could be a breaking change for some extensions. We should think on how to tackle such issues. Do we want to wait until a next manifest version?

Rob--W commented 2 years ago

Sounds like a good move to make extensions safer by default. The concern of still wanting to use the non secure http protocol should be fixable by overwriting the default csp and not including the upgrade-insecure-requests right?

Yes. It is easy for developers to revert to the current, insecure status quo if desired. "upgrade-insecure-requests" is a tool designed to migrate easily to https. Regardless of what happens with this proposal, it is still good practice to use secure schemes (https/wss) in the extensions' source code where possible.

Agreed with @hanguokai, this could be a breaking change for some extensions. We should think on how to tackle such issues. Do we want to wait until a next manifest version?

Backwards-compatibility is a relevant concern. That's why, if implemented, Firefox will introduce this to MV3 (https://bugzilla.mozilla.org/show_bug.cgi?id=1797086) and mention this change in relevant communications.

Although Chrome has already shipped MV3 for a while, the vast majority of the extensions in the CWS are still MV2. I'll defer to @dotproto to weight the benefits of this proposal against the potential fallout of extensions in Chrome.

The negative impact of this potentially breaking change can be reduced further by offering good messaging (in the browser's developer tools, on the chromium-extensions mailing lists, to developers, etc.). Well-maintained extensions will become aware of the approaching change and update their extensions before users notice.

dotproto commented 2 years ago

The proposed change (as of the first edit) seems like a good change to me. That said, I haven't been able to discuss it with my team in order to determine Chrome's stance.

Agreed with @hanguokai, this could be a breaking change for some extensions. We should think on how to tackle such issues. Do we want to wait until a next manifest version?

At the moment I don't think we should wait until the next manifest version bump to make this change, but I'm open to changing my mind. Here are the major factors influencing my perspective.

The Chrome Web Store's Developer Program Policies require extensions to securely transmit user data. The proposed change will help ensure developers meet this requirement. Of course, not all requests made by extensions are transmitting user data, so the ability to opt into insecure request handling via a custom CSP provides those that need it with an escape hatch.
The inclusion of upgrade-insecure-requests will help minimize (but not eliminate) the impact of this change on existing extensions. Extensions that have customized the extension_pages CSP will have already opted out this.
Chrome has a history of making similar security-minded breaking changes to the extensions platform without a manifest version bump. The specific example that leaps to mind is the cross-origin request change for content scripts that launched around Chrome 85.

I agree that browsers should have advanced warning for this change and communicate/document the rollout schedule for this change.

carlosjeurissen commented 2 years ago

During the 2022-10-27 meeting, it was brought up this could potentially conflict with potential issue with extensions having permission for http: but not for https:. So I have opened an issue specific for this so we can continue this discussion: https://github.com/w3c/webextensions/issues/304

w3c / webextensions