[HTTPS-Everywhere] Proposal: ruleset maintainers and test URLs

Dave Warren davew at hireahit.com
Mon Aug 18 11:24:19 PDT 2014


On 2014-08-18 09:13, Nick Semenkovich wrote:
> I love the ideas!
>
> Automatically disabling broken rules could really improve the user 
> experience -- and adding some TravisCI hooks to pull-requests would be 
> great.
>
> Two thoughts
> - How would we go about automatically disabling rules?
> Should we have some protected class of "super stable" rules (e.g. 
> Twitter's SSL shouldn't be disabled if there's a transient curl test 
> failure.)
>

The downside is that this potentially enables an attack vector that 
opens up sites to the very downgrade attacks that HTTPS Everywhere 
exists to prevent.

Without HTTPS Everywhere, nothing stops sites from applying redirections 
from HTTP to HTTPS themselves, so HTTPS Everywhere's primary purpose is 
to prevent downgrade attacks, and to apply a client-side enforcement of 
HTTPS on sites that don't redirect it themselves.

With automatic validation and deactivation of rules in the event that a 
destination page fails, all an attacker needs to do is to keep a site's 
HTTPS busy or offline for some period of time for HTTPS Everywhere to 
disengage, returning the site to a less secure state.

Like with so many things in security, there is an obvious security vs 
usability tradeoff here, is it better to return an insecure version of a 
page, or an error message and an unusable site?

Obviously if this is a permanent situation, the rule should be disabled 
and removed, but in the case of a temporary error on the HTTPS side, I'd 
be very nervous about automatically removing a layer of security.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren




More information about the HTTPS-Everywhere mailing list