Backblaze / B2_Command_Line_Tool

The command-line tool that gives easy access to all of the capabilities of B2 Cloud Storage
Other
544 stars 126 forks source link

Sign releases (gpg) #744

Open maltfield opened 3 years ago

maltfield commented 3 years ago

Currently it is not possible to verify the authenticity or cryptographic integrity of the downoads from github.com because the releases are not cryptographically signed.

This makes it hard for your users to safely obtain the b2 software, and it introduces them (and potentially their servers) to watering hole attacks.

Steps to Reproduce

  1. Go to the releases page https://github.com/Backblaze/B2_Command_Line_Tool/releases
  2. Click download
  3. ???

Expected behavior: [What you expected to happen]

A few things are expected:

  1. I should be able to download the Backblaze release signing PGP key out-of-band from popular third-party keyservers (eg https://keys.openpgp.org/)
  2. I should be able to download a cryptographic signature of the release (or, better, the releases' digest file, such as a SHA256SUMS.asc file) along with the release itself
  3. The downloads page itself should include a link to the documentation page that describes how to do the above two steps

Actual behavior: [What actually happened]

There's just literally no information on verifying downloads, and it appears that it is not possible to do so.

ppolewicz commented 3 years ago

Github is the only official mirror that we trust to distribute our binaries. Github also holds our cryptographic keys in Secrets. If github wanted to create a malformed release, they would just sign it using our keys.

If anyone other than github would try to distribute the release, they'd have to make a MITM attack between the user and github, which is impossible since github uses HTTPS, HSTS and certificate pinning. Also if someone would be capable of doing this, they would be targeting banks, not b2 cli users.

Creation of signatures and documentation for verification could be a nice enhancement to b2 cli. Same as with #745, I'd like to invite you to contribute a patch, if you think it's worth your time. We'll help test it and we'll upload our public keys where necessary, but since the attack vector is not an immediate threat (attacker would have to somehow be able to intercept a binary served by github over https, or attacker would have to compromise github), for me personally it's not a top priority right now.

maltfield commented 3 years ago

MITM attack between the user and github, which is impossible

Sorry, but https doesn't protect you from MITM attacks. The problem isn't the crypto; it's the PKI

In the past, the maintainers of these root stores have removed CA's root certs for corporations who had lost control of their root certificates. 8 Similarly, there have been several historic controversies with CAs operated by government agencies. 10 And also with private entities that have been accused of being malicious actors (cyber-mercenaries) on behalf of governments. 12

Note also that HSTS is TOFU and therefore is useless unless there's browser persistence. And HPKP has been deprecated (sadly).

See also my notes in #745. Release signing isn't something that should be automated.

ppolewicz commented 3 years ago

As a first step, we are adding Signing Windows releases: https://github.com/Backblaze/B2_Command_Line_Tool/pull/746