Let the browser upgrade subcontent

[Madis0]

Unlike HTTPS Everywhere, this extension doesn't take care of sub-requests triggered from HTTP-only sites. For now, it outright ignores those requests, because using the same approach with those (retrying on error) is very complicated and has significant drawbacks.

What about adding an option to use the Upgrade-Insecure-Requests header, similar to Smart HTTPS? That way the browser would handle everything properly, without needing the extension to redirect links back and forth.

There is also a flag security.mixed_content.upgrade_display_content but I think it is not exposed to extensions just yet. Bug 1435733

[claustromaniac]

As far as I know, this would be no different than doing a client-side redirection of those requests to HTTPS in that, when a server does not support HTTPS, said requests would fail. However, it would differ in that it would be less secure, because it requires the first batch of headers to be sent unencrypted, therefore those packets can be sniffed.

I had a different idea to deal with this limitation yesterday, and I'm still considering it. To elaborate: HTTPZ could automatically build a list of 3rd-party secure sites (similar to how it builds a list of secure 1st-party sites since the latest beta release) and always redirect those hosts to HTTPS. It wouldn't be a perfect solution either, but at least it shouldn't break anything.

Edit: Forgot to mention that security.mixed_content.upgrade_display_content seems to apply to HTTPS sites only (mixed content usually refers to insecure requests triggered by DOM elements on secure sites).

Edit2:

It wouldn't be a perfect solution either, but at least it shouldn't break anything.

On second thought, it would introduce compatibility issues with other extensions. That, plus the other less important downsides, seem like a compelling enough reason not to implement my idea either... bummer.

[jingofett]

Sorry if this is the wrong place to ask this but: would using "Forbid mixed content" in uMatrix alleviate some of the security issues caused by using this extension over HTTPS Everywhere?

[claustromaniac]

@jingofett

No. Mixed content is unrelated to this issue.

Mixed content refers to insecure requests triggered from secure pages. The known issue quoted in the OP is about insecure requests triggered from pages that are served insecurely in the first place. HTTPS Everywhere uses a ruleset to know when servers support HTTPS, hence it can redirect those requests without having to go through hoops for that. This extension uses a trial-and-error approach, which is ineffective for that (because of limitations). It's a pretty small trade-off though, because when you visit a site over HTTP you are already exposed, so having some third party content also served over HTTP is not much more of a risk (you're already potentially screwed in that scenario).

HTTPS Everywhere has an option (disabled by default) that uses the Upgrade-Insecure-Requests header to tell servers that you prefer to upgrade requests to HTTPS when possible, and if the servers can't do that, those requests are dropped (they fail). That is what @Madis0 was mentioning (edit: actually, he mentioned Smart HTTPS, not HTTPS-E, but whatever), and from what he said, I'm pretty sure he only suggested that because he thought the browser would fall back to HTTP instead of dropping the request (but that's not how it works, AFAIK).

PS: Although it doesn't really have anything to do with this issue, I would still recommend everyone to block mixed content. An alternative to using uMatrix for that is to set the following prefs in about:config

security.mixed_content.block_active_content = true (defaults to true)
security.mixed_content.block_display_content = true
security.mixed_content.block_object_subrequest = true

[jingofett]

@jingofett

No. Mixed content is unrelated to this issue.

Mixed content refers to insecure requests triggered from secure pages. The known issue quoted in the OP is about insecure requests triggered from pages that are served insecurely in the first place. HTTPS Everywhere uses a ruleset to know when servers support HTTPS, hence it can redirect those requests without having to go through hoops for that. This extension uses a trial-and-error approach, which is ineffective for that (because of limitations). It's a pretty small trade-off though, because when you visit a site over HTTP you are already exposed, so having some third party content also served over HTTP is not much more of a risk (you're already potentially screwed in that scenario).

HTTPS Everywhere has an option (disabled by default) that uses the Upgrade-Insecure-Requests header to tell servers that you prefer to upgrade requests to HTTPS when possible, and if the servers can't do that, those requests are dropped (they fail). That is what @Madis0 was mentioning, and from what he said, I'm pretty sure he only suggested that because he thought the browser would fall back to HTTP instead of dropping the request (but that's not how it works, AFAIK).

PS: Although it doesn't really have anything to do with this issue, I would still recommend everyone to block mixed content. An alternative to using uMatrix for that is to set the following prefs in about:config

security.mixed_content.block_active_content = true (defaults to true)
security.mixed_content.block_display_content = true
security.mixed_content.block_object_subrequest = true

Thank you for the detailed response. Much appreciated!

[claustromaniac]

I've done some more research and tested a number of things locally, and I'm sorry to say there's apparently no way for me to add this without breaking other very important extensions (like content blockers). I better wait for bug 1462989 to get solved before trying to do anything about this. Unfortunately, that can take years (literally)...