[HTTPS-Everywhere] EFF Ruleset

Drake, Brian brian2 at drakefamily.tk
Thu Dec 30 05:56:11 PST 2010


I haven’t read all the details of STS but my understanding is that, at a
given point in time and on a given domain, it is either enabled or disabled
on the entire domain and, if it is enabled, the browser rewrites
http://domain/… requests by changing http to https. However, STS does not
support any other rewriting.

Therefore, if STS is disabled on secure.eff.org, then that domain is open to
all the problems of not using HTTPS at all; if it is enabled, then
http://secure.eff.org/wiretapping (for example) will be rewritten to
https://secure.eff.org/wiretapping and fail (except for users using HTTPS
Everywhere or some other rewriting software!).

The other changes to rulesets are, in some cases, “micro-optimisations”; in
other cases, they avoid certificate errors. Avoiding certificate errors
seems like something we should pursue more actively, at least by adding a
note to the ruleset-writing instructions and any other appropriate place.

I don’t really understand the process for submitting patches, not knowing
anything about GitHub except what’s given on the HTTPS Everywhere site.

On Thu, Dec 30, 2010 at 0535 (UTC-8),
<https-everywhere at lists.grepular.com>wrote:

> I'm aware of how STS works but I don't understand what you think is a
> problem here. Can you explain in more detail?
>
> The other changes to rulesets that you've mentioned so far strike me to
> be micro-optimisations. I suspect that if you submit patches they'll be
> accepted; the people running this project seem quite keen to accept
> new/modified rulesets. *most* of the existing rulesets can probably be
> optimised in one way or another.
>
> Mike
>
> On 29/12/2010 0720 (UTC-8), Drake, Brian wrote:
> > In fact, if they failed to do this, wouldn’t it create a problem with
> > STS (Strict Transport Security), which I understood the EFF to have
> > implemented on all their systems that support it?
> >
> > On Wed, Dec 29, 2010 at 0452 (UTC-8), Drake, Brian
> > <brian2 at drakefamily.tk <mailto:brian2 at drakefamily.tk>> wrote:
> >
> >     Then, as I originally asked, why doesn’t the EFF reprogram their
> >     servers so that
> >
> >
> >     https://secure.eff.org/wiretapping
> >
> >     and similar URLs return a redirect to whatever their preferred
> >     address is instead of a 404 error?
> >
> >     On Wed, Dec 29, 2010 at 0304 (UTC-8),
> >     <https-everywhere at lists.grepular.com
> >     <mailto:https-everywhere at lists.grepular.com>> wrote:
> >
> >         [snip]
> >
> >
> >     --
> >     Brian Drake
> >     [snip]
> >     All content created by me Copyright © 2010 Brian Drake. All rights
> >     reserved.
> >
> >
> > --
> > Brian Drake [snip]
> > All content created by me Copyright © 2010 Brian Drake. All rights
> reserved.
>
> --
> Mike Cardwell [snip]
> <https://mail1.eff.org/mailman/listinfo/https-everywhere>


--
Brian Drake

Alternate (slightly less secure) e-mail: brian at drakefamily.tk
Alternate (old) e-mail: brianriab at gmail.com

Facebook profile: Profile ID
100001669405117<https://ssl.facebook.com/profile.php?id=100001669405117>
Twitter username: BrianJDrake <https://twitter.com/BrianJDrake>
Wikimedia project username:
Brianjd<https://secure.wikimedia.org/wikipedia/meta/wiki/User:Brianjd>(been
inactive for a while)

All content created by me Copyright © 2010 Brian Drake. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101230/0eab2a70/attachment.html>


More information about the HTTPS-everywhere mailing list