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
_______________________________________________
HTTPS-Everywhere mailing list
[email protected]
https://lists.eff.org/mailman/listinfo/https-everywhere
