Https-everywhere: forum.crucial.com misformatted

[phillipremaker]

I'm not clever enough to figure out why, but forum.crucial.com (aka: https://crucial.i.lithium.com/) is wildly misformatted with the current rulesets. Not sure why. Easy to reproduce, goes away when plugin disabled.

When I agree to "Load Unsafe Scripts" it works.

Is there any way I should report this to Lithium/Crucial?

Looks like the site doesn't support https in the first place, and in a partial https load of other parts of the site, it doesn't like http scripts?

[fuglede]

Would certainly be nice, if you could report it to them, since there is no way to fix it on our end without disabling the ruleset for part of the site; on the other hand, fixing it _might_ be straightforward for them to do.

What you're seeing is mixed content blocking: References to content to be loaded over an insecure connection, while the main page itself was fetched over a secure connection. In this particular case, the style sheet http://crucial.i.lithium.com/skins/1710767/5595FF97230CA5CF96E6B9BA60653CCF/crucial_skin_v2-1571727682.css is blocked, which is what causes the design to break. Similarly, a lot of JavaScript is blocked. To see a full list of what's going wrong, try opening your browser console (keyboard shortcut F12 in Firefox and Chromium), and refresh the page. By allowing your browser to "load unsafe scripts", you allow it to fetch references to active content (styles, scripts, etc.) over http, even though the initial connection was secure.

So in short, for them to fix their site, it would suffice to update all those http://crucial.i.lithium.com/ references to either //crucial.i.lithium.com/ or (preferably) https://crucial.i.lithium.com/.

[phillipremaker]

I know just enough about regexp to be dangerous. Where do I learn how to write rulesets? Would it just be a mater of adding rules for lithium.com subdomains?

Also, when you add an HTTP exception, how does it swing back if the site ever uses HTTPS? Or does someone just have to notice and change the rule when working https is added?

[fuglede]

First of all, eff.org has a bit of information on what rulesets are like in general, and what they are composed of.

Regarding your question of exceptions, there's basically two answers. One kind of exception is what is obtained through the tag, as mentioned in the page linked above. Those just mean that whatever applicable rules we might have should not be applied to the pattern within the exclusion. This has no influence on what happens when a webmaster decides to redirect on their own. A slightly different answer is that provided by the HTTPS-HTTP redirect mentioned at the bottom of the guide page which will force a page to be loaded insecurely; sometimes necessary, but it's normally possible to avoid that.

Now, for the issue problem at hand, it looks like the offending rule is the last one in the ruleset in Crucial.xml, which is redirecting content from forum.crucial.com to the broken page. The quick-and-dirty solution (which I would happily merge) would be to remove that rule, and to add in the heading comment of the ruleset a note on why it is no longer there for future maintenance. Another, and somewhat more involved solution would be to remove the rule but then go in and look at exactly which parts of http://crucial.i.lithium.com/ may still be secured; often, static content like this image may be secured just fine, even if the page itself can not be without mixed content issues.

In general, the ruleset looks a bit outdated and could probably be tidied up a bit. For instance, I noticed that they serve images on the pics subdomain which is not covered by any of the current rules.

A final note about a bug which is pretty confusing if you don't happen to know it (and which might actually be the reason that you are asking the way you are, I just realize): I mentioned that the reference to http://crucial.i.lithium.com/skins/1710767/5595FF97230CA5CF96E6B9BA60653CCF/crucial_skin_v2-1571727682.css is what is causing issues, so it seems like we should just be able to replace that with https://crucial.i.lithium.com/skins/1710767/5595FF97230CA5CF96E6B9BA60653CCF/crucial_skin_v2-1571727682.css on our end and happily move on. Unfortunately, due to this bug in Firefox and Chrome, it's not that easy: the style sheet is blocked before we get the chance to secure it.

[phillipremaker]

Thanks for taking the time for such a detailed answer. I have also poked at the lithium folks to fix the source page not to specify the HTTP transport. They have a legitimate certificate for *.i.lithium.com, so it is silly that they would use http. In fact, They should probably always grab scripts with https even if the rest of the site uses http. The best case if to fix the source to be more secure by default rather than coding in an exception.

Also, forum.crucial.com is a DNS alias to crucial.i.lithium.com, so forum.crucial.com throws a certificate mismatch error. ince they use wildcard certs, a Subject Alternative Name is not a good solution. They need better https practices for their Lithium sites!

[fuglede]

Sounds good; in my experience, plenty of devs out there are willing to fix issues like these, but in case they're not, or if they do not respond before the next release, let us just fix it here.

[J0WI]

closed by #4934