[wp-trac] [WordPress Trac] #25252: Pin the WordPress.org SSL certificates

[WordPress Trac]

#25252: Pin the WordPress.org SSL certificates
----------------------------+--------------------
 Reporter:  rmccue          |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  3.7
Component:  HTTP            |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |
----------------------------+--------------------

Comment (by dd32):

 I originally said we had 3 options available to us, in reality, we also
 have a 4th, we use our own root certificate.

 Using our own root certificate would mean we no longer rely on a 3rd party
 to sign requests to api.wordpress.org.
 There are several downsides to that approach:
 1. Browsers won't trust our root CA, so HTTPS connections to a domain
 signed by us would fail
 2. Our root CA would be no more secure than a existing certificate
 authorities, only difference being is that we'd know who is signing the
 certs and how long they're going to be around for
 3. We'd need to sign requests to multiple domains with that, at present,
 `api.wordpress.org`, `global.wordpress.org`, `downloads.wordpress.org`,
 and even, `wordpress.org`.
 4. If a cert we signed with our root CA was compromised (or the root cert
 itself even) then we'd have no way of revoking it (we don't currently
 support certificate revoking in WP_HTTP, partially due to using cURL which
 doesn't allow it)
 5. I'm also not sure how a CDN would play with a self-signed certificate
 (if we have to offload downloads or something to a CDN in the future)

 1 & 3 are the major technical issues, and both could be worked around, for
 example, instead of signing those domains directly, we'd sign
 `*.signed.wordpress.org` instead with our CA, leaving `*.wordpress.org`
 protected by a browser-trusted CA. (the server could simply treat
 `*.signed.wordpress.org` as a loopback proxied request, ie.
 `api.signed.wordpress.org` would internally proxy to `api.wordpress.org`)

 ----

 I don't like the idea of suggesting we pin to the GoDaddy certificates, as
 we shouldn't be relying upon a single authority for this. If the
 certificate ever changes in the future, users who haven't updated will be
 forced to manually (by FTP, themselves) update WordPress.. How often do
 you come across a WordPress 2.x install in the wild?

 However, I do believe we could probably release without pinning the
 certificate, it would allow for MITM attacks on hosting companies, but
 that's already something that is possible, they can either intercept our
 API calls, or our download calls and serve up a altered ZIP..

 We could also release with GoDaddy pinning, and update the list of
 certificate authorities in a future release, or even to our own
 certificate (but that would also require changing all the URL's we connect
 to for API's and downloads).

 The approach taken in [attachment:25252.diff] is still our best bet, the
 only questions are
 1. What CA's to pin to
 2. What domains to pin (currently wordpress.org, *.wordpress.org, but
 ideally it'd be *.signed.wordpress.org, signed.wordpress.org so we're not
 forever locked in, we could change it in the future to
 *.packages.wordpress.org using a different CA)

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25252#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software