[HTTPS-Everywhere] EFF Ruleset

[Drake, Brian]

Nice explanation of how STS works; I’ll consider that when I get my own
HTTPS-enabled website. By the way, I don’t understand why the STS header
can’t specify a more general host (like *.example.com), nor why it needs to
expire at all.

My discussion of secure.eff.org is obviously about those cases where HTTPS
Everywhere is not being used or the EFF rule is not enabled, in which case
STS should do the job instead, but won’t in this case. Since the EFF is a
big believer in STS, why don’t they make it work?

As for the certificate errors, rules like:

<rule from="^https?://(de-de|www\.)?facebook\.de/" to="
https://www.facebook.com/"/>

help to avoid certificate errors when a request like

https://de-de.facebook.de/

is generated by something else (besides HTTPS Everywhere). (
de-de.facebook.de uses a certificate that’s only trusted for facebook.com)
I’m arguing that we should be more actively encouraging the writing of rules
like this (Admittedly I haven’t found any built-in rulesets where this
applies and hasn’t already been done, but it does apply to Adobe, for one.).

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

> On 30/12/2010 0556 (UTC-8), Drake, Brian wrote:
>
> [snip]
>
> > Therefore, if STS is disabled on secure.eff.org <http://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!).
>
> HTTPS-Everywhere usually negates the need for STS for sites with
> rulesets. You will not visit a http version of the site in the first place.
>
> > 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 believe all the existing rulesets which are enabled by default do not
> have any certificate errors. That is how it is *supposed* to be anyway.
> There are a few rules which generate certificate errors but they are set
> to disabled by default.
>
> --
> Mike Cardwell https://secure.grepular.com/   https://twitter.com/mickeyc
> Professional  http://cardwellit.com/ http://linkedin.com/in/mikecardwell
> PGP.mit.edu   0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> 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/5348f035/attachment.html>