[HTTPS-Everywhere] EFF Ruleset

[https-everywhere at lists.grepular.com]

On 30/12/2010 13:56, Drake, Brian wrote:

> 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.

Basically. If a user goes to https://www.example.com/ at any point, and
the response contains an STS header, and they then come back later and
enter www.example.com in their browser, instead of going to
http://www.example.com/ it will go to https://www.example.com/ - The
header contains expiry information too.

One place were people usually screw up is by redirecting:

http://example.com/

To:

https://www.example.com/

And setting the STS there. When you do that, the STS only applies to
"www.example.com", so when the user comes back later and sticks
"example.com" in their browser, it is not subject to the STS and thus a
MITM attack can be performed. If you really want the website to exist at
https://www.example.com/, you should do two redirects:

http://example.com/ to https://example.com/

Then:

https://example.com/ to https://www.example.com/

Setting STS on both domains. Unfortunately this can cause certificate
problems if you're not using a domain with multiple CNs or
subectAltName. My own website is actually subject to this problem at the
moment because I was only made aware of the issue a few weeks back and I
don't consider it to be a critical issue (on my site) so haven't fixed yet.

> 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