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

[Maxim Nazarenko]

<offtopic>
I'd argue that HTTPS Everywhere main purpose is BOTH redirect from http to
https for sited not doing that server-side and prevent downgrade attack.
Ultimately, the extension is a crutch, site operators can and should deploy
redirection and HSTS with preloaded lists, but...
</offtopic>

More on topic, I don't think automatically disabling rules is a good idea.
When a break is detected during CI tests, the rule maintainer is notified,
and then it is up to him to take measures. When something breaks for an
end-user, one can always disable the rule. I don't think we should make
security vs usability tradeoffs instead of end users.

My suggestion was more like "Press here to report a broken rule" button,
i.e. a way for end users to notify the rule maintainer. Optionally, we may
ask for additional details such as URL being accessed etc, that must be
opt-in naturally. Using Tor for reports is a good idea, and we employ
captcha if spam becomes a problem.

Best regards,
Maxim Nazarenko


On 18 August 2014 22:24, Dave Warren <davew at hireahit.com> wrote:

> 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
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140819/51d13cc5/attachment-0001.html>