On Tuesday, September 17, 2013 4:58:28 AM UTC-4, Gervase Markham wrote:
> Can we work out what those requirements are by studying the pinning
> configuration for google.com and its subdomains in Chrome?
There are two different things that I fear are getting conflated here:
1) HSTS (i.e. "HTTPS required") preloading.
2) Public key pinning.
Chromium contains a list of HSTS preloads which is open to anyone and which I,
currently, manually manage.
Chromium also contains preloaded pinning for Google, Twitter, Tor and
CryptoCat. This is also manually managed, but is not open to everyone as it
takes much more time to handle these.
*In the strongest terms*: no other client should take the pinning preloads from
Chromium. Pinning is fairly high risk and we have broken large numbers of
clients with it in the past. It would be very bad for anyone to start
hardcoding those sorts of assumptions without our knowledge. (If you wish to
deal with Twitter etc directly, then you are, of course, free to do so.)
When it comes to the HSTS preloading, I am rather bored of managing that list.
Although I'm not sure whether the answer is to scan the network and gather it
automatically, or to concentrate only on high value targets, like pinning, and
let the HSTS headers do the rest.
Google production is fairly bad at sending HSTS headers I'm afraid and we do
have several special cases. Some of that was historically my fault, which I've
now fixed but it remains the case that not all teams at Google are configuring
their services to send HSTS headers. It is something that I and others continue
to remind them of.
>From memory, the HSTS exceptions for Google are that charts.apis.google.com is
>deprecated but still somewhat common on the web and doesn't support HSTS,
>while apis.google.com is, otherwise, HSTS.
We also have a number of domains ("gmail.com", "googlemail.com" etc) which
require SNI to serve the correct certificate and therefore cannot be HSTS is
the user has only enabled SSLv3. We used to expose this in the preferences UI
for some reason but have removed it now. It may well be that we shouldn't be
worrying about supporting that configuration any longer, but it's still there
for the moment.
Cheers
AGL
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
