WordPress's core development team began a discussion recently about the challenges involved in enabling plugin/theme developers to manage their own keys. This led to a discussion about Project Gossamer and our designs for zero-authority public key infrastructure (za-PKI).
And then WordPress.org, being halfway across the bridge, decided to make a sharp left turn and discuss rolling back the Ed25519 signature for core updates in favor of "SSL with checksums".
I do want to reiterate that I want to see package signing come to fruition, so rolling back the current implementation is primarily about clearing the way to ensure it's done properly, rather than trying to rush a half-baked solution.
This development was accompanied by a blog post with a confusing title ("SSL for auto updates"), for which the biggest takeaway seems to be: Nobody understands server-side HTTP requests.
If that's the case, to any WordPress freelancers in the audience: you'll want to read this post to distinguish yourself from the majority of your peers.
WordPress 3.7 was released on October 24, 2013 and introduced an automatic update mechanism to ensure security fixes would be automatically deployed on all WordPress sites, in an effort to prevent recently-patched vulnerabilities from being massively exploited in the wild. This is widely regarded by security experts as a good idea.
However, the WordPress automatic update feature had one glaring Achilles' heel: If a criminal or nation state were to hack into the WordPress update server, they could trigger a fake automatic update to infect WordPress sites with malware.
This isn't just a theoretical concern, it could have happened if not for WordFence's security researchers finding and disclosing an easy attack vector into their infrastructure.
WordPress 5.2 was released on May 7, 2019 and provides the first real layer of defense against a compromised update infrastructures: offline digital signatures.
Recommended reading: What's a digital signature?
Despite the abundance of coverage on this material on the Internet, these resources lack the clarity that we look for when drafting recommendations for software developers and system administrators. Additionally, many of them are showing their age and desperately need to be brought up to speed with a modern understanding of real world cryptography.
Our initial design constraints were as follows:
Today, we'd like to talk about some of the challenges we've encountered, as well as some of the features that have landed in CipherSweet since its inception, and how we believe they are beneficial for the adoption of usable cryptography at scale.
If you're not familiar with cryptography terms, you may find this page useful.
Will tomorrow bring costly and embarrassing data breaches? Or will it bring growth, success, and peace of mind?
Our team of technology consultants have extensive knowledge and experience with application security and web/application development.
Want the latest from Paragon Initiative Enterprises delivered straight to your inbox? We have two newsletters to choose from.
The first mails quarterly and often showcases our behind-the-scenes projects.
The other is unscheduled and gives you a direct feed into the findings of our open source security research initiatives.