Https-everywhere: Google: No More Mixed Messages About HTTPS

[ivysrono]

Google Online Security Blog: No More Mixed Messages About HTTPS

We may need to do same thing these months.

For example, Inserts all -mixedcontent rulesets upgrade-insecure-request to https response in order to resolve some common MCB.

[cschanaj]

Since C81 release, both Chrome and Firefox will block active mixed content. However, Firefox does not automatically upgrade passive mixed content. We might want to introduce the CSP header to HTTPS pages in non-EASE session to avoid browser specific bahaviour (related #14600).

Still, upgrade-insecure-request might introduce CORS issues. Firefox added the upgradeToSecure directive in FF59 for extensions to partially resolve it (limited to trivial rewrites, see #15092). It makes me curious how Google Chrome will handle this in its implementation.

Related: #18160, #15070

[pipboy96]

@zoracon Any idea how to proceed?

[zoracon]

Since the major browsers are planning to upgrade their approach to MCB I think this is a great opportunity to introduce similar treatment to try out the CSP directive upgrade-insecure-request in non EASE mode. My general thoughts are:

• Is it better to catch active and passive mixed content? For example, possibly just giving this treatment to scripts and not images?
• Should we provide the option to "opt-out" of mixed content protection like the browsers do?
• This is good for finally normalizing more rulesets and one day doing away with platform = mixedcontent.
• Also, when/if FF and Chrome block mixed content completely, Should we act as a proxy for mixed content anymore?

TLDR;
I think it's a good idea to introduce the CSP directive upgrade-insecure-request, for mixed content, particularly scripts, as the default and probably giving the user an "opt out" in he Options page of the HTTPS Everywhere as a start.

[gloomy-ghost]

First off, the main concern of upgrade-insecure-request in the past was img that could make it through browser's MCB, but would become broken over https if upgraded. If browsers start to aggressively block all mixed content, it makes more sense for _them_ to auto-upgrade MCB as a step to minimise breakage, which is also mentioned in the Google blog. When they really go that far, I'm pretty happy to see https everywhere to become more of a community HSTS preload list.

Is it better to catch active and passive mixed content? For example, possibly just giving this treatment to scripts and not images?

It seems to be a misconception of an extension's capability, we simply can't do the browser's job here. I just confirmed using Firefox that all requests must pass MCB before they even reach webRequest.onBeforeRequest. Inserting upgrade-insecure-request in the CSP header is just a way to tell browser's MCB mechanism _beforehand_ to upgrade a http request if it meets one. So at the moment we can only toggle it on or off for a page, not a fine-grained control.

I had an idea about scanning a page's DOM using a content script to check any http resources, but it sounds pretty messy. Also since the response comes after header, we are only left with adding a meta tag in HTML rather than using webRequest. This could introduce a time lag that allows some requests to slip through. Given the current status, it's probably not worth it to develop this feature anyway.

[zoracon]

It seems to be a misconception of an extension's capability, we simply can't do the browser's job here.

Oh, I agree with this. Which is why I asked should we even act as a proxy (when being so creates a potential gap for insecure requests to go through). This currently kind of creates a strange effect in EASE mode on sites like Qualys and https://mixed-script.badssl.com/where the mixed scripts they test with have https but makes it seem like the insecure mixed content is loading since the extension amended the request.

Right now Firefox allows users to opt out of mixed content protection, but I am glad Chrome took the step to just wholesale block mixed content all together in 2020. I, for one will be glad since it allows us to simplify all of our mixed content rulesets.

I had an idea about scanning a page's DOM using a content script to check any http resources, but it sounds pretty messy. Also since the response comes after header, we are only left with adding a meta tag in HTML rather than using webRequest. This could introduce a time lag that allows some requests to slip through. Given the current status, it's probably not worth it to develop this feature anyway.

Yea, if we start touching the DOM it turns into an extension that does more than modify network requests. A sign that it's not worth the issue.

---

I know Firefox currently gives users the means to opt out of mixed content protection, but wonder if they will follow Chrome's lead on this.

I only still would like to try to see what falls on us as a responsibility since browsers still let insecure requests go through. From what I understand they will block insecure mixed content on pages that land on HTTPS. Since the extension will bring users to the secure pages, does that leave a gap on us to insure that mixed content protection is still available? That's the main concern I have at this point.

[gloomy-ghost]

The browsers' move will make MCB no longer a security issue as in things load over plaintext, so there isn't much left to do. And since both browsers will do it by default, I don't think we should be in the way of those who know what they are doing to opt out.

https everywhere's job will basically be reduced to
1) make sure a page loads over https and everything else will automatically be over https; or,
2) try to upgrade some linked resources (probably just some CDNs, if that matters) when the page itself is not available over https

[zoracon]

To revisit this (and as I prep for the inevitable fetch test), the best next step is probably to let the browsers handle MCB now. Especially after seeing a few issues already with how our requests from the extension can interfere with the browser's security measures for mixed content. (For example, browser side tests for mixed content often fail because the mixed content tested have a HTTPS counterpart. Therefore the test throws a false positive on mixed content passing through). So going to kick off deprecating the platform = mixedcontent attribute soon as a means to normalize these rulesets even further.

This is pretty great for the rulesets and shows how far the land of HTTPS has come.

[pipboy96]

@zoracon What are the primary issues delaying the fetch test right now? I would like to help fixing them.

[zoracon]

@zoracon What are the primary issues delaying the fetch test right now? I would like to help fixing them.

Right now there are no blocks necessarily. I just have to sit down and carve out time soon to set up the tests in three different timezones.

A particular issue I am trying to think of a proper solution for merging a ruleset file into one and the logic behind that for any changes that occur across the 3 timezone tests. RE: https://github.com/EFForg/https-everywhere/pull/17000. Doing just git diff --name-only <base commit> won't remedy this. But I just have sit down this week and think about this more efficiently.

[pipboy96]

@zoracon Can you explain what needs to be done (in Keybase if you want, or here) in more details?

[zoracon]

@zoracon Can you explain what needs to be done (in Keybase if you want, or here) in more details?

I can discuss here. This portion of the fetch test where I need to set up environments is mainly internal work that can't be done within the community. Maybe, for the next one I can set it up where the community can, since you all (repo maintainers) are in different timezones. Which would be a great development.

I just ask patience for those waiting since we are balancing MV3 ongoing developments, uploading HTTPSE to the Edge store, updating the HTTPSE page, etc.

If you'd like a task, maybe start looking into how we can deprecate the mixed content platform attribute. I'm definitely open to suggestions on the best way to handle that from the maintainers. :)

Thanks you for volunteering and checking in.