[HTTPS-Everywhere] HSTS rules

William Budington bill at eff.org
Wed Apr 27 14:43:39 PDT 2016


On Wed, 27 Apr 2016 14:40:07 -0700, William Budington wrote:
> On Wed, 27 Apr 2016 14:24:24 -0700, Jacob Hoffman-Andrews wrote:
> > 
> > On 04/27/2016 01:53 PM, Alexander Buchner wrote:
> > > If a site is in the HSTS preload list, it has set the
> > > includeSubDomains directive, since this is a requirement to get into
> > > the list. So I understand that for sites where the browser has the
> > > HSTS flag with includeSubdomains it shouldn't matter if the cookies
> > > have the secure flag or not since there is no way for them to get sent
> > > over http, right? So having rules for sites which are already on the
> > > HSTS preload list seems to be unnecessary to me and we could/should
> > > delete them.
> > I agree. I wasn't aware of the includeSubDomains requirement to get on
> > the preload list when I wrote this message. I assume that applies to
> > both Chrome and FF?
> 
> I wouldn't assume all sites on the HSTS preload list have the include_subdomains directive set.  This may be a new requirement, or a requirement which is standard unless some kind of special request is made.  In these cases, domains submitted before the requirement changed or upon a special request may not have include_subdomains set.  Case in point: you can see in the preload list[1] that 'paypal.com' does not have include_subdomains set.
> 
> 1. https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json

Also looks as though they don't have it set in headers, either:

    legind at X1 ~ $ curl -s -D /dev/stdout https://paypal.com | grep Strict-Transport-Security
    Strict-Transport-Security: max-age=63072000

> 
> > 
> > Also, FWIW: We did a batch deletion last year of a large-ish number
> > (~200) of rulesets that were originally autogenerate from HSTS preload
> > lists. The remaining rulesets that overlap with HSTS should be
> > relatively few in absolute size, although there is still some value in
> > removing them, because if they have complex rewrites, those could cause
> > bugs.
> > 
> 
> 
> 
> 
> > _______________________________________________
> > HTTPS-Everywhere mailing list
> > HTTPS-Everywhere at lists.eff.org
> > https://lists.eff.org/mailman/listinfo/https-everywhere
> 
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere


More information about the HTTPS-Everywhere mailing list