HTTPS Everywhere not working on all sites

[echosa]

Description

The built-in HTTPS Everywhere doesn't seem to work for all sites.

Steps to Reproduce

1. Visit https://www.speedtest.net
2. See that it is secure, so https is available.
3. Visit http://www.speedtest.net
4. See that it is not secure and did not redirect to https automatically.

Actual result:

Visiting http://www.speedtest.net should have resulted in an https request.

Expected result:

Visiting http://www.speedtest.net did not result in an https request.

Reproduces how often:

100% for speedtest.net. I don't know what all other sites can reproduce.

Brave version (chrome://version info)

Brave | 0.56.2 Chromium: 70.0.3538.35 (Official Build) dev (64-bit)
Revision | 28dcb499844fa40c28d5f62e337876cb936f79f5-refs/branch-heads/3538@{#678}
OS | Mac OS X

Reproducible on current release:

• Does it reproduce on brave-browser dev/beta builds?
  Yes, at least on dev (what I'm using).
• Does it reproduce on browser-laptop?
  Yes, the same thing happens.

[echosa]

Updated the description after trying this in browser-laptop. It has the same issue.

Note that the EFF's HTTPS Everywhere extension in Firefox handles this correctly.

[tildelowengrimm]

We just checked that our rules are up to date, which should resolve this. Let me know if it doesn't and I'll re-open.

[bbondy]

It sounds like this wasn't actually verified that the steps in comment 0 were valid or not @tomlowenthal nor that updating the list helped. So we should leave this open and fix or verify it is fixed.

[sreeware]

The issue is still there. When I load http://www.speedtest.net, it is not taking me to the https version of the website, but loads the 'http' site with the 'not secure' warning by the side. True for couple of other websites too. I have confirmed that HTTPS Everywhere is enabled under the 'Brave shields defaults' settings.

Version 0.56.15 Chromium: 70.0.3538.110 (Official Build) (64-bit)

[diracdeltas]

@fmarier if you have a chance, could you take a look at this one?

[fmarier]

I grabbed the version of the XPI we use in our builder script and extracted its ruleset. I found that the Speedtest.net is disabled by default in version 2019.9.19:

{
    "name": "Speedtest.net (partial)",
    "default_off": "Breaks site",
    "target": [
        "speedtest.net",
        "c.speedtest.net",
        "www.speedtest.net"
    ],
    "exclusion": [
        "^http://c\\.speedtest\\.net/crossdomain\\.xml|^http://www\\.speedtest\\.net/+(?:$|\\?)"
    ],
    "rule": [
        {
            "from": "^http://c\\.speedtest\\.net/",
            "to": "https://www.speedtest.net/"
        },
        {
            "from": "^http://(?:www\\.)?speedtest\\.net/",
            "to": "https://www.speedtest.net/"
        }
    ]
},

whereas starting in version 2018.10.31, it's enabled again:

{
    "name": "Speedtest.net (partial)",
    "target": [
        "speedtest.net",
        "www.speedtest.net",
        "c.speedtest.net",
        "zdstatic.speedtest.net"
    ],
    "rule": [
        {
            "from": "^http:",
            "to": "https:"
        }
    ]
},

This actually got fixed at the end of September in EFForg/https-everywhere#16643 and so updating our rules (or merging brave/https-everywhere-builder#12) should resolve this.

[fmarier]

I have just updated the list and forced an update to Brave HTTPS Everywhere Updater - Version: 1.0.10 in chrome://components.

Both https://https-everywhere.badssl.com and http://speedtest.net now get upgraded properly.

[srirambv]

@fmarier do we have a PR for this fix on https://github.com/brave/https-everywhere-builder that can be linked? If so need to add the issue to a milestone and verify it.

[diracdeltas]

@srirambv: Since HTTPS Everywhere updates are independent from Brave updates, should this just be in whatever the next milestone is? the fix is brave/https-everywhere-builder#12

[srirambv]

@diracdeltas 0.60.x sounds good for this to be put in 👍

[GeetaSarvadnya]

Verification passed on

Brave	0.60.27 Chromium: 72.0.3626.96 (Official Build) beta (64-bit)
Revision	84098ee7ef8622a9defc2ef043cd8930b617b10e-refs/branch-heads/3626@{#836}
OS	Windows 10

• Verified the STR mentioned in the description
• Logged new issue HTTPS Upgrades count increasing on each page reload #3321

Verified passed with

Brave	0.60.26 Chromium: 72.0.3626.96 (Official Build) beta(64-bit)
Revision	84098ee7ef8622a9defc2ef043cd8930b617b10e-refs/branch-heads/3626@{#836}
OS	Mac OS X

• Verified STR from description

Verification passed on

Brave	0.60.26 Chromium: 72.0.3626.96 (Official Build) beta(64-bit)
Revision	84098ee7ef8622a9defc2ef043cd8930b617b10e-refs/branch-heads/3626@{#836}
OS	Linux

Used STR from description

[cbrunnkvist]

HTTPS Everywhere is perhaps an unfortunate branding for the extension if it does not probe & switch to HTTPS everywhere, but instead work only for a small set of preconfigured websites?

[echosa]

@cbrunnkvist Proposed fix: add an asterisk to the name.

HTTPS Everywhere*

Problem solved! ;-)

[mixedCase]

Can we reopen this? This bug could be redefined as a branding issue or a technical problem. Truth is that this isn't truly HTTPS everywhere since it never tries upgrading on its own; and whenever I'm visiting less known sites (which is extremely often when it comes to local sites) they simply can't be in the list and must be probed by the browser to work just like the HTTPS everywhere extension from the EFF does.

[bsclifton]

@diracdeltas should we update HTTPS Everywhere?