https-everywhere
https-everywhere copied to clipboard
Direct HTTP link to a Firefox extension doesn't redirect correctly if EASE is enabled
Type: code issue
This might be related to #17774. I've tested with HTTPS Everywhere version 2019.6.27 and the latest Beta and Nightly versions of Firefox.
Steps to reproduce:
- Enable EASE.
- Find an HTTPS URL to an
.xpi
file, change it to HTTP, and visit the modified URL. For example, try clicking on http://www.eff.org/files/https-everywhere-2019.6.27-eff.xpi.
Expected results:
The browser prompts the user to download and to install the extension.
Actual results:
The page gets redirected to the moz-extension://
blocking page and the .xpi
file cannot be downloaded.
I think the reason is Firefox doesn't let you tamper with .xpi requests.
I think the reason is Firefox doesn't let you tamper with .xpi requests.
But this is strange, www.eff.org
is preloaded https://hstspreload.org/?domain=www.eff.org. This request should, thoretically, always go through HTTPS...
Update:
For some domains that are preloaded and without ruleset coverage, e.g. http://hstspreload.org/https-everywhere.xpi, http://youtube.com/https-everywhere.xpi, http://bugzilla.mozilla.org/https-everywhere.xpi the URLs are redirected correctly.
For domains that are not preloaded and without ruleset coverage, e.g. http://http.badssl.com/https-everywhere.xpi the warning page also appears.
For domains that are not preloaded and with ruleset coverage, e.g. http://www.google.com/https-everywhere.xpi, the URL is redirected to HTTPS correctly.
A reasonable deduction from the above is that *.eff.org is not preloaded. But it appears on the firefox preload list https://hg.mozilla.org/releases/mozilla-release/raw-file/FIREFOX_68_0_RELEASE/security/manager/ssl/nsSTSPreloadList.inc
Should be fixed by #18233.
This issue still exists, cc @zoracon.
Revisiting, when I click on http://www.eff.org/files/https-everywhere-2019.6.27-eff.xpi, i get the install prompt. Is that still not the case for others?