Some of the information out there about where we are and where we're going is a bit disparate and lost in the noise of many separate Tasks and impending gerrit commits. This is an attempt to bring together a coherent view of the current state of things, the next upcoming steps, etc. If you know information that isn't here (missing Task refs, etc) please feel free to correct it! The Description here will evolve as we go, use comments to discuss, etc.
- **Definitions**
- Canonical domains: wikipedia.org, wikimedia.org, wiktionary.org, wikiquote.org, wikibooks.org, wikisource.org, wikinews.org, wikiversity.org, wikidata.org, wikivoyage.org, wikimediafoundation.org, mediawiki.org, wmfusercontent.org, w.wiki.
- Non-canonical domains: Anything not in the list above. These are generally redirect-only domains such as `wikimedia.ee`, `wikizpravy.cz`, `wikimediacommons.jp.net`, etc
- Traffic Clusters: These are the `text`, `upload`, `maps`, and `misc` traffic clusters which do standardized TLS termination for the bulk of all our HTTP[S] traffic to all of our domainnames.
- One-off Services: These are individual internet-facing HTTP[S] services which are **not** terminated by one of the standard traffic clusters above and run their own independently-configured internet-facing server software (e.g. nginx or apache). They are in our control and hosted in our datacenters.
- Third-party: These are HTTPS[S] service hostnames in our canonical domains which are hosted by a 3rd-party service for us.
- **Current State of Affairs - HTTPS, Redirects, and HSTS**
- Our desired state is:
- Modern TLS (v1.2, FS/AEAD ciphers enabled, sane ordering, no publicly-known TLS flaws)
- HTTP: 301 redirect of GET/HEAD to HTTPS, 403 denial of other methods.
- HSTS with 1yr duration, preload, includeSub
- All canonical domains (not individual service hostnames) submitted to the Chromium preload lists
- Outstanding Exceptions:
- Traffic clusters:
- Canonical domains:
- stream.wikimedia.org - Certain subpaths for legacy rcsream service lack HTTP->HTTPS redirect due to existing socket.io client incompatibilities. New replacement eventsream service (under same hostname) does have redirects, and old paths will be deprecated and this exception removed by roughly mid-2017.
- Non-canonical domains (all are currently serviced by our Traffic Clusters):
- No valid certificates. Task to move these to a separate service with LetsEncrypt certs: T133548
- One-off Services
- One minor issue with civicrm (Funrdaising): T137161
- Third-party
- store.wikimedia.org - T128559
- blog.wikimedia.org - T105905
- A few issues still in Fundraising 3rd party services: T137161
- ** Current State of Affairs - Crypto Compatibility vs Security Tradeoffs **
- Dashboard for negotiated ciphers: https://grafana.wikimedia.org/#/dashboard/db/tls-ciphers
- As a general rule, none of our HTTPS endpoints should support SSLv2 or SSLv3. I don't believe there are any exceptions to this today. The only client browser anyone cares much about which lacks TLSv1.0 (or higher) support and is blocked by this is IE6 on Windows XP (which, due to our redirects and lack of SSLv3 support, cannot access our HTTPS-redirected sites at all anymore).
- We maintain [[ https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/wmflib/lib/puppet/parser/functions/ssl_ciphersuite.rb | explicit ciphersuite lists in our puppet repo ]] that are intended to be shared by all TLS termination software for all cases. There are three choices a site/service can choose from at this time: strong, mid, and compat. Descriptions straight from ssl_ciphersuite.rb:
- strong: Only TLSv1.2 with PFS+AEAD ciphers. In practice this is a very short list, and requires a very modern client. No tradeoff is made for compatibility. Known to work with: New FF/Chrome, IE11, Java8, Android 4.4+, OpenSSL 1.0.x, Safari 9. Definitely broken with: Safari <= 8. IE11 support requires either DHE support or an ECDSA key.
- mid: Supports TLSv1.0 and higher, and adds several forward-secret options which are not AEAD. This is compatible with many more clients than "strong". With a DHE-capable server, should only be incompatible with IE8/XP, ancient/un-updated Java6, and some small corner cases like Nokia feature phones. With a non-DHE server, compatibility is also lost with Android 2.x, OpenSSL 0.9.8, and more Java6 clients.
- compat: Supports most legacy clients, PFS optional but preferred.
- The specific contents of the cipher lists above will evolve over time.
- Traffic clusters - Currently on `compat`, with ECDSA+RSA keys and DHE support
- One-off services - Mostly on `mid`, if not they're on `compat` or very similar. The further `mid` upgrades are blocked on upgrading underlying hosts to Debian Jessie.
- **Other Ongoing/Future Work**
- HPKP - T92002 - We've dithered back and forth a lot on exactly how we're going to implement this, as it's tricky and scary and involves doing a better job at key management than we do today.