Open maltfield opened 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.
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.
As a first step, we are adding Signing Windows releases: https://github.com/Backblaze/B2_Command_Line_Tool/pull/746
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
Expected behavior: [What you expected to happen]
A few things are expected:
SHA256SUMS.asc
file) along with the release itselfActual behavior: [What actually happened]
There's just literally no information on verifying downloads, and it appears that it is not possible to do so.