-
Notifications
You must be signed in to change notification settings - Fork 1.1k
add option for http URLs to try https first and fallback in case of errors #16488
Comments
|
From the Smart HTTPS extension description, one weakness is glaring: SH is susceptible to downgrade attacks- a network attacker can simply block HTTPS and it will allow loading HTTP instead. Also, it will not work on sites where, for instance, the HTTPS endpoint for the same resource is on a separate subdomain or path. That's why we have those rules bundled with the extension. The best solution in this case is to just turn on "Block all unencrypted requests," which does upgrade users connections when they try to access HTTP sites, but also blocks them from accessing HTTP sites if it can't upgrade and gives a warning letting the user decide whether they want to try HTTP instead. See #7936 |
|
The suggestion I made would be after all the rules have been applied
and would not affect either original or rewritten https URLs.
The current setup for http URLs is to just download them unencrypted,
the proposed suggestion would incrementally upgrade them permanently
once they are successfully loaded once over https.
A set of https whitelists will never be enough to cover the entire
Internet so some automated mechanism is also needed. For the most part
having http and https resources on different URLs is a thing of the
past so just rewriting all URLs to https by default would mostly work.
The automated mechanism could also be used as input for the rulesets.
The "Block all unencrypted requests" option does not sound like it does
what you describe it does. I expected it would just block all requests
that are http instead of rewriting them to https. I think it should be
renamed "Upgrade all unencrypted requests to https" and two other
options should be added:
"Unsuccessful upgrades to unencrypted request: block or downgrade?"
"Report unencrypted upgrades to EFF: none, success, failure or both?"
This would make it easier for users to express their preferences.
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
i use Smart HTTPS (SH) and would love to switch to https-everywhere (HE), but i am not because such cases are so common. there are still many, many sites that are not inventoried by HE that SH catches. and yes, SH can trivially be hijacked, if you type the URL in cleartext. that is already the case with HE if the site is unknown and "Block all unencrypted requests" is disabled (the default). So for me, using HE without that setting is insufficient. So i tried to enable it but because it broke on those sites, it made HE unusable. I tried to add an exception for that site, but couldn't figure out how to do so. I think the current behavior of the "Block" setting would be acceptable if there was a one-click escape hatch somehow (well, two click: click on the extension icon, click on the exception). Is that something that could work? |
|
@pabs3 Thanks for enumerating these possibilities, we may pursue this in the future. But I think the best thing for right now is to at least allow users to disable HTTPS Everywhere on specific sites |
|
In the future, we may want to have sub-options that are disabled by default, such as:
... and then we would allow rulesets to express that certain domains only support HTTP. This may be a contentious suggestion though, and warrants some discussion. |
Type: feature request
With Firefox < 60 I used a plugin called https-finder that would, for each http URL:
Fetch the https version of the URL instead.
If that succeeded, store the domain as one that should always be https.
If that did not succeed, fetch the original http URL instead.
It would be nice if https-everywhere could do this itself. There are some other options for this but it would be nice to have this in https-everywhere.
https://mybrowseraddon.com/smart-https.html
https://github.com/Rob--W/https-by-default
The text was updated successfully, but these errors were encountered: