[wp-trac] [WordPress Trac] #49200: Allow Developers to Cryptographically Sign Their Own Plugins/Themes with the Gossamer Public Key Infrastructure (PKI)

Thu Jan 16 04:09:34 UTC 2020

#49200: Allow Developers to Cryptographically Sign Their Own Plugins/Themes with
the Gossamer Public Key Infrastructure (PKI)
------------------------------------------+------------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:  (none)
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Upgrade/Install               |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:                                |     Focuses:
------------------------------------------+------------------------------

Comment (by paragoninitiativeenterprises):

 Hi @ayeshrajans. Thank you for the insightful comment.

 I think you misunderstood the architecture a bit.

 The only package that will be installed on any WordPress machine is
 [[https://github.com/paragonie/libgossamer/blob/master/composer.json|libgossamer]],
 not [[https://github.com/paragonie/gossamer-
 server/blob/master/composer.json|gossamer-server]] (which can also exist
 as a WordPress plugin so people don't have to trust external servers that
 run slim, etc.). The version of libgossamer that will be included in the
 WP core patch will only depend on `wpdb`, `Wp_Http`, and the already-
 present sodium_compat. (We aren't using Composer to automatically fetch
 dependencies when we write a WordPress patch.)

 A lot of the concerns about external dependencies and trust follow from
 this misunderstanding, so I shall not dwell on them further. If you feel
 any of them are still worthy of examination in the context of a
 libgossamer dependency, not a gossamer-server dependency, please let me
 know which ones. We don't want to beat a dead horse (as the idiom goes),
 but we also want to make sure any standing criticisms are fully discussed.

 > I find the update signing in Composer and Phar-IO to be least invasive
 yet functional.

 Incidentally, we are preparing a congruent proposal for
 Composer/Packagist.

 The problem with signed Phars is that you can strip them easily. Simply
 delete the pubkey file and replace the OpenSSL signature with a SHA1 hash
 and PHP will happily run unsigned code again.

 > They rely on openssl and gpg, which had several security
 vulnerabilities, but are trusted available to be used by pretty much every
 LAMP stack.

 OpenSSL and PGP would downgrade our proposal to use:

 * [[https://www.deepinstinct.com/2020/01/15/cve-2020-0601-what-you-need-
 to-know|X.509]]
 * [[https://latacora.micro.blog/2019/07/16/the-pgp-problem.html|PGP]]
 * [[https://robotattack.org|RSA]] - See also:
 [[https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
 #asymmetric-signatures|Don't use RSA]] and
 [[https://blog.trailofbits.com/2019/07/08/fuck-rsa/|Seriously, Stop Using
 RSA!]]

 The experts in software security and cryptography are almost unanimously
 opposed to the incumbent tools. The reasons are varied, but mostly:

 1. They introduce a lot of unnecessary complexity, which makes the
 security predictions pessimistic.
 2. They invite you to chase the lowest denominator of cryptography
 primitives (e.g. RSA with PKCS1v1.5 padding) rather than simply secure
 [[https://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf|boring
 crypto]] (PDF).
 3. Many of these projects were designed by hobbyists and advocated by
 activists who were well-meaning but largely out of their depth when it
 comes to secure protocol design.

 Aside: Libgcrypt (which powers GnuPG) is basically an entire undergraduate
 course in side-channel cryptanalysis. Instead of fixing GPG, experts are
 designing tools to replace it entirely, like
 [[https://github.com/FiloSottile/age|age]] and
 [[https://github.com/jedisct1/minisign|minisign]]. Do not resuscitate.

 With all that in mind, opting for RSA/PGP/X.509 isn't being conservative
 with security. It's regressive, in this case.

 > Because of the lack of an audit

 If an audit would give the WordPress community confidence in what's being
 offered, surely the WordPress community can fund one?

 If anyone reading this is wondering why we insist the community fund an
 audit, ask yourself, "Is it reasonable to expect the person or team who's
 put hundreds of hours of unpaid cryptography engineering work into solving
 this problem, with no plans to monetize their solution, to further pony up
 tens or even hundreds of thousands of dollars out of their own pocket to
 pay their competitors to conduct an audit?"

 If an audit is necessary, then it should be on the community to fund one.

 If the community cannot or will not fund an audit, then the "lack of an
 audit" objection has no standing and should be put to rest in future
 discussions about this project unless the funding calculus changes.

 > and the novel approach instead of using established PKI, all these 35.5%
 of web sites would be indirectly trusting your organization to keep the
 word and take your PKI approach instead.

 What trust does the WordPress community have to give us, exactly?

 * The entire Gossamer PKI is deterministic and auditable. No one can abuse
 it without getting caught.
 * We will not have any privileged position (e.g. the "Super Provider"; the
 WordPress security team will have control over that).
 * Our designs are 100% open source, and permissively licensed.

 The standard for cryptographic transparency is called "nothing up my
 sleeves", wherein all design decisions are justified clearly and nothing
 gives the designer an unfair advantage (e.g. a backdoor).

 Gossamer isn't just "nothing up my sleeves" transparency, it's more like
 "stark naked with an RFID tracking chip that anyone can monitor" levels of
 transparency.

 The only trust that anyone has to have is that we implemented the
 algorithms correctly (but only if you don't have ext/sodium installed) and
 that our protocol is actually secure.

 (The entire point of Gossamer's design is to keep power in the hands of
 the community, rather than an elite class of experts. We abhor power-
 seeking behavior.)

 > I think the question ultimately comes down to the politics and trust
 considerations ... and whether the PKI approach can stand against the
 masses.

 (Snipped for the above consideration about dead horses.)

 If the answer turns out to be "No, the PKI approach cannot stand against
 the masses," then it will require an scientific breakthrough in modern
 cryptanalysis and secure protocol design.

 Breakthroughs are difficult to predict, but given the slowed rate of hash
 functions being broken (SHA-2 is still secure, despite decades of
 attempts), it seems unlikely to happen.

 > What sort of trust do we (as WordPress community) has for Gossamer to be
 included by default in world's most wide-spread web platform?

 This is an excellent question that everyone should ask themselves
 earnestly. We'd love to hear what the community needs, and then outline a
 strategy to meet those needs.

 If the WordPress community feels that they need cryptography experts to
 chime in, Paragon Initiative Enterprises is ''kind of the only game in
 town'' for PHP cryptography. (This wasn't our doing, either. We abhor
 gate-keeping.)

 > As someone who wishes WordPress (and many PHP packages for that matter)
 to adopt automatic updates that trust for developers are established
 without secure channels or middleman, I really wish your efforts will
 fruitful.

 Thanks!

 > May I ask what prevents you from providing this solution as a plugin?

 Insecure by default means insecure in practice. Making this an optional
 feature means most people will not benefit from better security.

 I mean, for all any of us know, this could all be for naught. While we're
 discussing ways to prevent a supply-chain attack, someone else could be
 ready to press the Enter key on their exploit to burn it all down. There
 are no guarantees in life, we just have to do the best we can.

 A temporary plugin can absolutely be developed for testing purposes prior
 to mass adoption, but the end goal should absolutely be ubiquitous
 deployment to the entire ecosystem.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49200#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform