SSL for auto updates

r44954 introduced experimental package signature verification for plugin and theme updates. That and subsequent commits from #39309 have proved useful in testing and experimenting with the use of cryptographic signatures for update verification. That work has progressed to a point where it has become clear that there are many complicated and difficult problems to solve in order for signatures to be used securely in practice, and that solving those problems requires cryptographic expertise that we don’t have enough of.

Based on the discussion in that ticket, there are essentially two possible ways to implement the key management infrastructure needed to use signatures in production:

  1. Build a certificate structure something like X.509, and implement secure APIs to allow for key revocation and rotation.
  2. Use something like Gossamer for distributed key management.

Since both of these options are long-term projects that require very careful design and testing, we need a short-term plan for improving the security of auto-updates while those more ambitious ideas are explored.

It appears that the sensible short-term solution is to shelve signatures for the moment and instead use checksum hashes delivered over HTTPS. By strictly enforcing SSL certificate checks, we can offer package integrity checks that are more secure than the status quo, and take advantage of SSL’s certificate infrastructure for authentication. That will allow us to move forward with auto-updates now, and continue to research and develop robust signature protocols for future release.

I propose we do the following for 5.3:

  1. Review the suitability of hashes provided by the core update APIs.
  2. Improve the core update code so as to always use SSL with certificate checking (on systems with functioning SSL).
  3. Implement compatibility checks and fallback options for systems without functioning SSL (perhaps requiring human intervention to manually verify updates).
  4. Implement end-to-end tests for update code, including SSL fallback, and tests for the update APIs and checksums.
  5. Review handling of edge cases and exceptions such as rollbacks.

To clarify: in this context, SSL refers specifically to using a secure connection to api.wordpress.org. It would not require SSL certificates to be installed on a WordPress site. Certificates would be used to verify the authenticity of wordpress.org itself.

Later versions of WordPress can make this obsolete by incorporating a well-tested system for signature verification once it is ready for production.

Enabling strict SSL for updates is a necessary step towards safely providing auto-updates. With this in place we eliminate the main technical blocker to two of the 9 Projects for 2019.