Mixed Content lightweight DOM trasversal

[SamuelePilleri]

This is kind of related to #2017 though not exactly the same.

When creating a rule, we can client-side rewrite page url, switching to https, but this potentially leads to MCB errors with URLs hardcoded in the document (related).

Most of them can be fixed with very simple JavaScript and CSS selectors, making the site usable out of the box:

document.querySelectorAll('*[href^="http://' + document.location.host + '" i]')
.forEach(function(value)
{
        value.href = value.href.replace(/^http/i, "https");
});

document.querySelectorAll('*[src^="http://' + document.location.host + '" i]')
.forEach(function(value)
{
        value.src = value.src.replace(/^http/i, "https");
});

This wouldn't generate any error because we are assuming that, if the current host (exact domain + port) works with HTTPS, then all resources served by the current host work with HTTPS.

Please note that *[src^="http://www.example.com" i] is a CSS4 selector (it takes advantage of case-insensitive attribute), but I've tested it on Firefox latest (54.0.1 on Windows, not sure when they introduced it) and it works, while in Chromium it is available since version 49 (see); I do not have Opera to test.

I don't know if this is possible under current HTTPS Everywhere design, but I think it would be a nice feature to have, either default or optional via a tag-rule in the XML rule specification:

<ruleset name="Example.com">
        <target host="www.example.com" />

        <rule from="^http:" to="https:" />

        <rewrite from='*[src^="http://www.example.com" i]' to="https://www.example.com" />
        <rewrite from='*[href^="http://www.example.com" i]' to="https://www.example.com" />
</ruleset>

[ghost]

I'm not sure if replacing href/src in pages is in scope of HTTPS Everywhere.

[SamuelePilleri]

This is the dilemma, I think authors should take a decision on this. I thought about this extension because it comes with a huge and updated database and solves pretty much the same problem, but some deep modifications should be done. Another solution to this issue is to selectively disable MCB on pages that are known to behave strangely, but I don't know if this is possible; something like this: ```xml <ruleset name="example.com">     <target host="www.example.com" />     <rule from="^http:" to="https:" />     <mcb disabled="true" /> </ruleset>‎ ```

[ghost]

@SamuelePilleri This is not possible since the WebExtensions-based extensions cannot disable MCB.

[SamuelePilleri]

How about modifying the response body before it gets parsed by the browser? I'm don't have any experience in plugin development, but looking at the code HTTPS.handleSecureCookies(req) does something similar with response headers. Thinking about <link>, <script> and <img> that cannot have children as far as I know, this would be a simple regex (I think elements that can have children would require a full XML parse, much more heavy).

Do you think that would be appropriate?

[SamuelePilleri]

Actually, I think a simple regex like this could make it:

<\w+[^>]+(?:href|src)="(http:\/\/)(([^\/"]+)[^"]*)"

[cschanaj]

Linking #8506

[iki]

#8506 seems to handle this universally, even for resources loaded by js/css

[iki]

oops, upgrade-insecure-requests CSP applies only to site resources, not 3rd part ones, so we need fixing resources in DOM too

[SamuelePilleri]

I was reading #8506 as pointed out by @iki. The topic is quite interesting from a technical point of view, so I would start focusing on "same host" resources.

Reading through MDN docs I've found default-src which description says:

The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.

I'm completely new to this and I still have a lot to figure out, but could that be used as a fallback for requests that fail to load with HTTPS? That way, resources on the same domain are guaranteed to work and others might work.

Something like this:

Content-Security-Policy: upgrade-insecure-requests; default-src http: 

I understand it isn't an optimal solution given that HTTPS Everywhere has a huge database that could be used to resolve this problem with higher accurancy, but it's better than nothing.

Anyone knows any other way or is working on something similar?