Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTPS Everywhere not working on all sites #1535

Closed
echosa opened this issue Oct 11, 2018 · 15 comments
Closed

HTTPS Everywhere not working on all sites #1535

echosa opened this issue Oct 11, 2018 · 15 comments
Assignees
Labels
bug feature/https-everywhere Issues related to the HTTPS Everywhere component of Shields feature/shields The overall Shields feature in Brave. priority/P3 The next thing for us to work on. It'll ride the trains. QA Pass-Linux QA Pass-macOS QA Pass-Win64 QA/Yes release-notes/include security

Comments

@echosa
Copy link

echosa commented Oct 11, 2018

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
Copy link
Author

echosa commented Oct 12, 2018

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.

@bbondy bbondy added this to the 1.x Backlog milestone Oct 16, 2018
@bbondy bbondy added the priority/P2 A bad problem. We might uplift this to the next planned release. label Oct 16, 2018
@tildelowengrimm tildelowengrimm added feature/shields The overall Shields feature in Brave. bug priority/P3 The next thing for us to work on. It'll ride the trains. and removed priority/P2 A bad problem. We might uplift this to the next planned release. labels Nov 6, 2018
@tildelowengrimm
Copy link
Contributor

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
Copy link
Member

bbondy commented Dec 2, 2018

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.

@bbondy bbondy reopened this Dec 2, 2018
@sreeware
Copy link

sreeware commented Dec 9, 2018

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)

@bbondy bbondy added priority/P2 A bad problem. We might uplift this to the next planned release. and removed priority/P3 The next thing for us to work on. It'll ride the trains. labels Jan 19, 2019
@diracdeltas
Copy link
Member

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

@fmarier fmarier self-assigned this Jan 19, 2019
@fmarier
Copy link
Member

fmarier commented Jan 21, 2019

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.

@tildelowengrimm tildelowengrimm added priority/P3 The next thing for us to work on. It'll ride the trains. and removed priority/P2 A bad problem. We might uplift this to the next planned release. labels Jan 22, 2019
@fmarier
Copy link
Member

fmarier commented Jan 24, 2019

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.

@fmarier fmarier closed this as completed Jan 24, 2019
@srirambv
Copy link
Contributor

@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
Copy link
Member

@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
Copy link
Contributor

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

@GeetaSarvadnya
Copy link

GeetaSarvadnya commented Feb 12, 2019

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 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
Copy link

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
Copy link
Author

echosa commented Apr 5, 2019

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

HTTPS Everywhere*

Problem solved! ;-)

@mixedCase
Copy link

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.

@fmarier fmarier added the feature/https-everywhere Issues related to the HTTPS Everywhere component of Shields label Jul 12, 2019
@bsclifton
Copy link
Member

@diracdeltas should we update HTTPS Everywhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug feature/https-everywhere Issues related to the HTTPS Everywhere component of Shields feature/shields The overall Shields feature in Brave. priority/P3 The next thing for us to work on. It'll ride the trains. QA Pass-Linux QA Pass-macOS QA Pass-Win64 QA/Yes release-notes/include security
Projects
None yet
Development

No branches or pull requests