Enable HSTS for all sites on the HSTS preload list

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Enable HSTS for all sites on the HSTS preload list

Tom Schuster
Like all other browser we use Chromium's HSTS preload list. However I
believe we are the only browser that requires those sites to also serve an
HSTS header. Thus we currently disable HSTS for almost 500 sites! (Well to
be fair, probably half of the sites don't even connect) I think we should
drop this restriction or do some serious outreach. For example all of
different yahoo search pages like xa.search.yahoo.com are excluded right
now. It doesn't seem like the restriction actually helps us drive adoption
in a meaningful way, endangers our users and we already made an exception
for google properties. Furthermore nowadays the preload regestration site
requires the header, so all new sites should have the header.

Cheers,
Tom
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Enable HSTS for all sites on the HSTS preload list

Daniel Veditz-2
On Tue, Jun 9, 2015 at 11:07 AM, Tom Schuster <[hidden email]> wrote:

> Like all other browser we use Chromium's HSTS preload list. However I
> believe we are the only browser that requires those sites to also serve an
> HSTS header. Thus we currently disable HSTS for almost 500 sites!


​We are not "disabling" HSTS for those sites: if the site is serving HSTS
headers when the user gets there then it will work perfectly fine.​


(Well to
> ​ ​
> be fair, probably half of the sites don't even connect)


What is the value of an HSTS pre-load for such a site?​

It doesn't seem like the restriction actually helps us drive adoption
> ​ ​
> in a meaningful way, endangers our users


​The restriction has nothing to do with "driving adoption"! We are trying
to avoid blackholed sites that our users can't reach because we have an
HSTS preload setting but the site doesn't actually use SSL (anymore?). If
that happens the only recourse is "go use IE for 6 weeks and try the next
Firefox version".

Furthermore nowadays the preload regestration site
> ​ ​
> requires the header, so all new sites should have the header.
>

But we can't tell the difference between "new" and "old" sites, at least
not without setting up a new mechanism to diff list updates against an
archived baseline. What would that gain us? When we go to check the new
sites they'll have the header and everything will be fine without having to
know they were the "new" ones.


​One case we miss right now are sites where they want to set
includeSubdomains on a logical domain that doesn't have an actual web
server. That is setting HSTS for farm.myco.com; includeSubdomains to catch
all xx.farm.myco.com​

-
​Dan Veditz​
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Enable HSTS for all sites on the HSTS preload list

Tom Schuster
Thanks for your answers.

On Tue, Jun 9, 2015 at 10:09 PM, Daniel Veditz <[hidden email]> wrote:

> On Tue, Jun 9, 2015 at 11:07 AM, Tom Schuster <[hidden email]> wrote:
>
>> Like all other browser we use Chromium's HSTS preload list. However I
>> believe we are the only browser that requires those sites to also serve an
>> HSTS header. Thus we currently disable HSTS for almost 500 sites!
>
>
> ​We are not "disabling" HSTS for those sites: if the site is serving HSTS
> headers when the user gets there then it will work perfectly fine.​
>
>
> I am aware of this, sorry this is just bad phrasing. Obviously those pages
want HSTS behavior, but for some reason can't use the header. Google
apparently is big enough to get away with this.

> (Well to
>> ​ ​
>> be fair, probably half of the sites don't even connect)
>
>
> What is the value of an HSTS pre-load for such a site?​
>
> I assume this happens when people add their page to the preload list
before launch. This means what could happen is that a page goes online
during our 3 month window, but after we generate the hardcoded list of that
release. Please also consider the other 250 odd pages that have some other
issue (mostly missing HSTS header)

> It doesn't seem like the restriction actually helps us drive adoption
>> ​ ​
>> in a meaningful way, endangers our users
>
>
> ​The restriction has nothing to do with "driving adoption"! We are trying
> to avoid blackholed sites that our users can't reach because we have an
> HSTS preload setting but the site doesn't actually use SSL (anymore?). If
> that happens the only recourse is "go use IE for 6 weeks and try the next
> Firefox version".
>
> This is not a valid argument, because IE and Chrome support HSTS for those
sites as well and would not work either.

> Furthermore nowadays the preload regestration site
>> ​ ​
>> requires the header, so all new sites should have the header.
>>
>
> But we can't tell the difference between "new" and "old" sites, at least
> not without setting up a new mechanism to diff list updates against an
> archived baseline. What would that gain us? When we go to check the new
> sites they'll have the header and everything will be fine without having to
> know they were the "new" ones.
> ​
>
>
This was mostly just meant as a possitve comment, that Google is actually
trying to get people to use this header. They still apparently allow
exceptions though.

> ​One case we miss right now are sites where they want to set
> includeSubdomains on a logical domain that doesn't have an actual web
> server. That is setting HSTS for farm.myco.com; includeSubdomains to
> catch all xx.farm.myco.com​
>
>
-
> ​Dan Veditz​
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Enable HSTS for all sites on the HSTS preload list

Brian Smith-19
In reply to this post by Tom Schuster
On Tue, Jun 9, 2015 at 8:07 AM, Tom Schuster <[hidden email]> wrote:

> Like all other browser we use Chromium's HSTS preload list. However I
> believe we are the only browser that requires those sites to also serve an
> HSTS header. Thus we currently disable HSTS for almost 500 sites! (Well to
> be fair, probably half of the sites don't even connect) I think we should
> drop this restriction or do some serious outreach.


Here's the history on why it is that way:

In the long run, every site should be HSTS, right? Thus, if things go well,
the size of the preload list will eventually increase to the point where it
includes every domain name. From time to time, people in the Firefox
development community make a big deal about how large Firefox is and how we
need to control bloat, because the size of Firefox has had a measurable
effect on what percentage of downloads of Firefox actually succeed, which
directly affects Firefox's market share. At some point, if HSTS adoption
goes well, the HSTS preload list will be too large to ship in some Firefox
products and the list will have to be pruned. (Note: How to compress the
HSTS preload list to put off this pruning was an interview question I asked
most candidates I interviewed.) To mitigate the negative effect of that
pruning, we (mostly I) decided to encourage all sites that get preloaded to
send the HSTS header, so they would still get the second-best level of
protection from HSTS even if they were cut from the preload list.

I'm not sure if Mozilla is still developing FirefoxOS, but if it is, then
either FirefoxOS needs to periodically refresh the preload list, which
costs users bandwidth which costs some of them real money, or FirefoxOS
needs to rely on sites using the HSTS header. Note that, at least two years
ago, all the entries in the HSTS preload list expire between the time Gecko
is frozen for a particular FirefoxOS release and the time the phone
actually ships, so the preload list basically didn't (probably still
doesn't) work at all for FirefoxOS. Since FirefoxOS didn't implement the
feature where it periodically updates the HSTS list, and because partners
would likely want to disable it in some markets even if it were
implemented, FirefoxOS relies solely on sites sending the HSTS header.

Similar issues also affect Firefox for Android, because although Firefox
for Android gets updated periodically, users aren't as good at keeping it
up to date as they are with desktop Firefox, so for many FxAndroid users,
the HSTS preload entries expire before they update.

Thus, partially in order to ensure that HSTS works as well as it can work
for FirefoxOS and Firefox for Android, we (mostly I, I guess) decided to
encourage sites to add the HSTS header, by only preloading them if they add
it.

Finally, we were (I was) hoping that Firefox would eventually get away from
using Chromium's preload list. Instead, I wanted us to scan the web looking
for sites that send the HSTS header and add them to Firefox's preload list
even if they were not on Google's preload list. This way, Google wouldn't
be the gatekeeper for HSTS preloading. Remember, at the time this was all
designed, the only way to get on the preload list was to email a particular
software engineer at Google, wait for him to tell you what things you
needed to fix on your site, and then wait for him to manually add the site
to the list. At least as of a few weeks ago, one or more software engineers
at Google manually check each site before they add it to that list, even if
the site applies for HSTS preloading through the mostly-automated tool they
built.


It doesn't seem like the restriction actually helps us drive adoption
>
in a meaningful way, endangers our users


It helps FirefoxOS and FxAndroid users, at least.


> and we already made an exception
> for google properties.


Google also makes us do this:
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#889



> Furthermore nowadays the preload regestration site
> requires the header, so all new sites should have the header.
>

Right.

Cheers,
Brian
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Enable HSTS for all sites on the HSTS preload list

Kevin Chadwick
On Tue, 9 Jun 2015 15:10:43 -1000
Brian Smith wrote:

> In the long run, every site should be HSTS, right?

I disagree for decently coded websites but that has been discussed
enough on this list already and so I won't repeat it.

The aim should be that in the long run, HSTS is not needed at all.

SSL everywhere is needless complexity that actually desecures
some servers and needlessly wastes energy whilst greatly increasing DOS
vulnerability (integrity) which in some cases is far more important
than transport security.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Enable HSTS for all sites on the HSTS preload list

Daniel Veditz-2
In reply to this post by Brian Smith-19
On Tue, Jun 9, 2015 at 6:10 PM, Brian Smith <[hidden email]> wrote:

> Thus, partially in order to ensure that HSTS works as well as it can work
> for FirefoxOS and Firefox for Android, we (mostly I, I guess) decided to
> encourage sites to add the HSTS header, by only preloading them if they add
> it.
>

The preload-list is supposed to address the first-use gap in the HSTS
feature. You're saying people use the HSTS feature to get on the pre-load
list? That's backwards!

-Dan Veditz
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Enable HSTS for all sites on the HSTS preload list

Brian Smith-19
On Thu, Jun 11, 2015 at 2:22 PM, Daniel Veditz <[hidden email]> wrote:

> On Tue, Jun 9, 2015 at 6:10 PM, Brian Smith <[hidden email]> wrote:
>
>> Thus, partially in order to ensure that HSTS works as well as it can work
>> for FirefoxOS and Firefox for Android, we (mostly I, I guess) decided to
>> encourage sites to add the HSTS header, by only preloading them if they
>> add
>> it.
>>
>
> The preload-list is supposed to address the first-use gap in the HSTS
> feature.
>

It does, because when a site is on the preload list then there is no such
gap.


> You're saying people use the HSTS feature to get on the pre-load list?
> That's backwards!
>

No, it isn't.

Read the requirements for getting on the Chromium preload list:
https://hstspreload.appspot.com/. They are actually stricter than Firefox's
requirements.

Cheers,
Brian
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security