We should aim for putting our primary domains onto browsers' HSTS Preload lists. This requires includeSubdomains, which creates multiple pragmatic issues for us right now. We may not be able to includeSubdomains on wikimedia.org any time in the near future due to all of the unrelated services in that domain. For the others (e.g. wikipedia.org, wikiversity.org, etc) the primary blockers are the random too-deep subdomains that we need to eliminate first, linked in blocked-by tickets here.
Description
Description
Details
Details
Customize query in gerrit
Event Timeline
Comment Actions
Change 222270 had a related patch set uploaded (by Chmarkine):
Wikidata - HSTS include subdomains and preload
Comment Actions
Change 223054 had a related patch set uploaded (by Chmarkine):
HSTS preload for Mediawiki and Wikimediafoundation
Comment Actions
Change 223207 had a related patch set uploaded (by BBlack):
HSTS: preload for all certs except wiki[pm]edia.org
Comment Actions
Change 227455 had a related patch set uploaded (by BBlack):
Add HSTS preload for wikipedia.org, refactor related regexes
Comment Actions
Change 227455 merged by BBlack:
Add HSTS preload for wikipedia.org, refactor related regexes
Comment Actions
Status update:
We've submitted all of the primary domains from our unified cert to the HSTS preload list, with the exception of wikimedia.org. This means the following list is preloaded (implies includeSubdomains):
wikipedia.org
wikibooks.org
wikinews.org
wikiquote.org
wikisource.org
wikiversity.org
wikivoyage.org
wikidata.org
wikimediafoundation.org
wiktionary.org
mediawiki.org
They were submitted in 3 batches with some timing gaps: first just wikidata.org, then most of the rest, and then finally wikipedia.org. All but wikipedia.org now appear in the Chromium project's git repo @ https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json (wikipedia.org was just submitted today, so it will get committed in a future batch update, probably sometime in the next week or two). This means they're all destined for some future release of FF, Chrome, Safari, and IE (11/Edge), but it could be several weeks or months before all of these browsers do new releases that include these new Preload updates. I haven't seen even wikidata.org appear in stable Chrome updates yet.
Comment Actions
Before wikimedia.org is ready to preload, how about emailing agl@chromium.org to request preloading some high traffic and sensitive subdomains of wikimedia.org, like commons, donate, payments, etc.?
Comment Actions
Technically, I think we can do that without a custom exception. We'd need to do a few things on our end regardless:
- Actually fix those cases (e.g. right now, www.commons still exists as well and needs killing)
- Change our HSTS output code to output "includeSub; preload" just for the sensitive hostnames, but not for wikimedia.org itself
- Submit them one by one.
But really, I'd rather hold off on going down that road just a little bit longer, at least until we've got a firm picture of the future path of this whole wikimedia.org problem. If we cave and start doing them one by one, it takes pressure off of solving the more-general problem and makes our lives more of a PITA to boot. It's unnecessarily complex for us and unnecessarily bloats the chromium list, and we may yet find a better solution for the remaining problems. The really fundamental issue here (more fundamental than the email.donate problems and such) is that wikimedia.org has two purposes in life which conflict for HTTPS/HSTS/HPKP purposes:
- The domainname in which a bunch of important public virtual service endpoints exist, like commons, meta, phabricator, payments, etc...
- The default domainname of absolutely everything in our infrastructure which just happens to have a public IP, including all kinds of things that aren't really public services: random individual machines that are accessed over their wikimedia.org hostnames for internal traffic, etc.
If we could rewind time, we'd probably split those purposes into two discrete domainnames to solve this problem. Another related option is to move almost all individual servers out of wikimedia.org and into our private network/DNS and mandate that LVS-routing is used to send public IP traffic into private HTTP(S) servers. Regardless, the primary pragmatic issues all revolve around Fundraising right now, and we're going to have some meetings with them to hash out options soon.
Comment Actions
wikipedia.org is already on the preload list! Among Alexa Top 10 websites, Wikipedia is the only one that has all subdomains preloaded!
https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json#3319
https://twitter.com/konklone/status/626538394202570752