11 ms·

Bitcoin 0.13.0 Binary Safety Warning

216 points by pigeons 10y ago

jjnoakes 10y ago
If they can't protect the binaries on their web site, how can they protect the keys and fingerprints they are publishing?
- grapehut 10y ago
  A state sponsored attacker can reasonably easy generate a valid ssl certificate to man-in-the-middle any website, and replace it with what ever they please. However, they wouldn't be able to forge a signature if checked against the right keys
  - xyzzyz 10y ago
    The point here is that how can you make sure the keys are right, if the attacker might also replace those?
  - schoen 10y ago
    > A state sponsored attacker can reasonably easy generate a valid ssl certificate to man-in-the-middle any website, and replace it with what ever they please Doing this against bitcoin.org is probably taking a pretty big risk. Remember that misissued certificates represent proof of their own existence, and, if disclosed publicly, should result in an investigation of how the certificate was created. They could also choose to start using HPKP and asking browsers to report pin failures. Then a browser that has visited the legitimate site before will report to someone if it encounters an inconsistent cert in the future. That would make using a misissued cert for this site into an even bigger risk. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Reporting https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Report...
    - chrisfosterelli 10y ago
      > Doing this against bitcoin.org is probably taking a pretty big risk. Although it wasn't by hijacking the public key infrastructure, it is worth noting that China has demonstrated in the past they have no issue performing country-wide man-in-the-middle attacks against a single site [1]. Given that some CA's are Chinese, it is not that unbelievable unfortunately... [1]: http://www.pcworld.com/article/2908912/chinas-great-cannon-ddos-tool-enforces-internet-censorship.html http://www.pcworld.com/article/2908912/chinas-great-cannon-d...
      - JoshTriplett 10y ago
        True, but that attack used an HTTP resource. An HTTPS MITM attack burns a CA; browsers will remove it from their trust stores. And we're getting close to the point that it can't go undetected, either; once browsers enforce Certificate Transparency for all CAs, it'll no longer be possible to conduct an undetected MITM attack.
    - jessaustin 10y ago
      Doing this against bitcoin.org is probably taking a pretty big risk. Anyone who can escalate into stealing BTC, can afford that risk.
    - ryan-c 10y ago
      When I was looking into Chinese browsers two years ago, a number of them did not correctly validate certificates on HTTPS sites. They might not need to burn a CA. It should also be noted that HPKP will ignore issues when the cert is signed by a locally installed CA.
      - jtl999 10y ago
        It won't ignore issues for when the CA chains back to a OS preloaded one (when there is a distinction between user-added and preloaded, not sure in other case. ie Linux.) I agree somewhat more could be done on this front however if you're in a position where an adversary can add user-added CA's to your system you have bigger problems to worry about.
- chrisfosterelli 10y ago
  The website is vulnerable in a much larger number of ways, since it involves significantly more infrastructure which is all vulnerable to state actors. A state could generate fake certificates, physically access hosting servers, or access the internet connections the website uses. There is a much smaller attack surface for keys. If you are talking about protecting the key fingerprint they posted on the website, the idea is by publishing them now that others can note the fingerprint and warning before any malicious actor would have a chance to respond. This is also the same key they've used in the past I believe, so it can always be compared to prior releases.
  - chatmasta 10y ago
    Is this a good case for distributing downloads via torrent? Or do you then face the same problem when linking to the torrent file?
    - chrisfosterelli 10y ago
      Downloading by torrent hash link is nice because it cannot be altered after release, while this isn't true with a link to a binary file on a website. However, you still have to verify the authenticity of the binary with keys if you don't trust the location you got the torrent hash from (ie, the bitcoin website). So yes, essentially the same problem I believe!
  - indolering 10y ago
    It also allows them to trace any potential attacks, a state actor would need to get access to the signing machine or the private key itself.
    - placeybordeaux 10y ago
      Thats assuming that the current page wasn't altered by the attacker.
      - indolering 10y ago
kondbg 10y ago
As someone who does not follow Bitcoin news, what makes this release special enough to warrant an advance warning?
- nfd 10y ago
  It may not be a matter of the release being particularly special; rather, they might've been tipped off to some insider information or otherwise be aware of some information they felt it'd be best not to describe in detail right now.
  - kanzure 10y ago
    Unfortunately, none of the Bitcoin developers are currently aware of any "insider info" at all. This was force-pushed by a single individual who has not been communicating with anyone about this alert.
- patio11 10y ago
  Maybe they're attempting to make the peer-to-peer network resistant to partitions caused by what is commonly called the Great Firewall Of China? In that case, they are not crazy to think that would draw adversarial attention. Mentioned more-than-obliquely here: https://www.reddit.com/r/Bitcoin/comments/4l564f/bitcoin_core_nonirc_meeting_summary_for_20160520/ https://www.reddit.com/r/Bitcoin/comments/4l564f/bitcoin_cor... (I have not been following this issue in close detail.)
- CydeWeys 10y ago
  It's nothing special about this release, it's just that this is a release. There's normally a trickle of downloads, which wouldn't be worth attacking because you'd be discovered quickly and most of your targets would be newbie users who don't have much coin worth stealing. Attack right at the moment that a new version is released, however, and you end up with your compromised binary distributed to way more people before it's discovered.
jimrandomh 10y ago
The key fingerprint mentioned is 01EA5486DE18A882D4C2684590C8019E36C2E964. (Mirroring into comments to make life difficult for anyone who wants to modify bitcoin.org's web page).
- cwkoss 10y ago
  Verified, this is what I'm seeing on that page as well.
  - orblivion 10y ago
    You can Google the hash too.
- CydeWeys 10y ago
  It would be great if the core devs used their PGP keys, many of which are very highly trusted in the PGP strong set, to sign this key so that it is obviously the real deal. Right now it's only signed by two keys, Wladimir J. van der Laan's and some unknown one. Stick a bunch of other core devs on it and re-post it!
- web007 10y ago
  Have you done the rest of the verification necessary to say this is legitimate? * Wayback to some months ago for the download page [1] * Confirm that the content presented matches the existing download content for the 0.12.1 release (or prior) * Confirm that the content for the "0.11+ key" is the same [2] * Confirm that the signed release for the 0.12.1 content is correct and valid * Request that (full-length) key from a public GPG server If you've done all of those things, it might be a good idea for you to sign that key and push it back up to a public GPG server - that help with web-of-trust, and somewhat legitimizes the key versus some arbitrary untrusted impostor. (I have done all of these steps, and signed with my key 9BB5251DE08569D4DEEA894C85D221C11DD01DF6) [1] http://web.archive.org/web/20160109193420/https://bitcoin.org/en/download http://web.archive.org/web/20160109193420/https://bitcoin.or... [2] http://web.archive.org/web/20160109193420/https://bitcoin.org/laanwj-releases.asc http://web.archive.org/web/20160109193420/https://bitcoin.or...
akanet 10y ago
One wonders: if publishing a key fingerprint on a website in advance is considered a reasonable warning, would a torrent magnet link prove just as effective?
- desdiv 10y ago
  0.13.0 isn't out yet, and I don't think you can create an "empty" torrent, publish the magnet link, then update the torrent with the actual file at a later date while keeping the magnet link the same.
  - akanet 10y ago
    Ah, I thought they had the release ready to go already.
  - brokenmachine 10y ago
    That's correct. A Magnet link contains a hash of the file/s so it can be verified to be identical to the original during download. So you can't put the hash in there if you don't have the file yet. https://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_containing_hash_.28xt.29 https://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_conta...
    - geocar 10y ago
      No. A magnet link contains a hash of the torrent file, which is an extensible format[1]. One can simply add data to malicious torrent file until it collides with the target[2]. [1]: http://www.bittorrent.org/beps/bep_0000.html http://www.bittorrent.org/beps/bep_0000.html [2]: https://malicioussha1.github.io/ https://malicioussha1.github.io/
      - versteegen 10y ago
        You're claiming that SHA1 has been broken, but it hasn't. Have a closer look at what's actually stated at [2]. Edit: from your [1] link I see that the hashing algorithm used in a mgnet link isn't actually fixed, and MD5 is one option. So yeah, I guess you actually can't trust the immutability of a magnet link without checking it's doesn't contain urn:md5 or urn:kzhash.
pigeons 10y ago
I feel irresponsible for submitting this since I'm told no one but the poster knows anything about this and this did not go through the normal checkin process for bitcoin.org. Waiting, we'll see...
- Taek 10y ago
  Vigilance around binaries is a good thing anyway. I hope though that this does not damage relations with the Chinese community, as singling them out without good cause is unjust.
  - MichaelGG 10y ago
    >without good cause China has been well known to MITM traffic. No one should be offended by pointing this out.
    - Buge 10y ago
      Yeah, and injecting Javascript malware. I haven't heard of them MITMing HTTPS though.
      - puetzk 10y ago
        http://ncjolt.org/googles-distrust-of-chinese-digital-certificates/ http://ncjolt.org/googles-distrust-of-chinese-digital-certif... CNNIC was the root of trust for a breach involving false certificates for gmail. They claim it was an accident. It might have been. It might not have been.
- pmorici 10y ago
  I'd say it's quite possible that someone is just trying to spread FUD to distract from the emerging plans to fork Bitcoin to bigger blocks that have been materializing in the past couple days.
orblivion 10y ago
Anybody know how this affects the Bitcoin PPA?
- kanzure 10y ago
  Do not use "the bitcoin PPA". Launchpad compiles this on their own infrastructure outside of the gitian build process. If, for some insane reason, if you must use "the bitcoin PPA", always check hashes, always verify the binaries are correct, and always check signatures regarding those particular hashes. edit: livejournal -> launchpad
  - orblivion 10y ago
    The PPA seems to be the recommended Ubuntu install instruction on bitcoin.org: https://bitcoin.org/en/download https://bitcoin.org/en/download Aren't all of Ubuntu's packages built on launchpad? It's interesting that you don't trust launchpad, should I not trust my OS either? And as far as checking signatures, that's what apt does automatically anyway, as I understand. I know people like Moxie insist that it's only acceptable to have the (at least) software's author sign the software. Well, personally I'd rather trust a larger organization with more reputation to lose. (Ideally I'd have both, of course, when we get to deterministic builds.) edit: Oh, deterministic builds is what gitian is. Okay I see your point :-) But still, why trust your OS at that point?
    - kanzure 10y ago
      Yes, deterministic debian is a good idea and we should make that happen.
      - orblivion 10y ago
        In the meantime, do you recommend against PPAs in general, or just for specific sensitive things like Bitcoin?
        kanzure 10y ago
jvehent 10y ago
bitcoin.org does not implement HPKP. Any government that controls a CA can generate its own cert for bitcoin.org, hijack the site's IP and replace this page with their own fingerprint.
- jlgaddis 10y ago
  And China has a root CA under their control. I'm on my iPad at the moment so I can't provide the fingerprints of it right now, but I remember "un-trusting it" on all of my machines a long while back.
  - l2dy 10y ago
    I believe there are two of them: "CNNIC Root" and "China Internet Network Information Center EV Certificates Root".
  - indolering 10y ago
    As does anyone with enough money to purchase a certificate authority or crack a certificate authorities servers.
  - barsonme 10y ago
    Also this: https://github.com/chengr28/RevokeChinaCerts/ https://github.com/chengr28/RevokeChinaCerts/
  - mynewtb 10y ago
    And the US, host of malicious entities like the CIA and NSA, has several root CA's under their control.
    - jlgaddis 10y ago
      Yes, of course. There's something like, what, around 400 root CAs, I think? I mentioned the .cn government (and their root CA(s)) because the article mentioned the .cn government, specifically, and the parent comment mentioned "any government that controls a CA". Obviously, any government with a) control over a root CA and b) control over their entire country's Internet access could carry this out. The article we're commenting, however, called out .cn by name.
kanzure 10y ago
So far, none of the others I have pinged about this has any info as to its veracity or background. Unlike most contributions to bitcoin.org, this one was pushed to the master branch without a corresponding pull request (a mechanism used to solicit review and feedback from others). https://github.com/bitcoin-dot-org/bitcoin.org/commit/5e0fd5292c936324660c680e4e99506da659c9fb https://github.com/bitcoin-dot-org/bitcoin.org/commit/5e0fd5... I suggest skepticism. We should be cautious of anyone skipping peer review processes, even for security incidents. Poor handling of these situations can lead to unintentional panic where panic of any kind is unhelpful to resolving issues. However, everyone should always be encouraged to check the signatures regardless of alerts, of course. Multiple signatures should always be checked, and not just Wladimir's signature. Use the gitian signatures repository to get other signatures, and always verify public key and signature data through multiple independent channels. gitian signatures repository: https://github.com/bitcoin-core/gitian.sigs https://github.com/bitcoin-core/gitian.sigs GPG build verification steps: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#verify-other-gitian-builders-signatures-to-your-own-optional https://github.com/bitcoin/bitcoin/blob/master/doc/release-p... gitian build steps: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-bu... gnupg CVE-2016-6316 from today https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/0003... Also, don't use gpg short ids. Always verify fingerprints. There are gpg short id matching keys floating around for some Bitcoin developers - for example, http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2346C9A6 http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint... check out the revoked key. ( This reply is x-posted from https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary... )
wildchild 10y ago
No worries they want to drive price down.
ipsin 10y ago
Is the concern here specifically related to the NSA Shadow Brokers hack (where they're supposedly auctioning the goods for bitcoin), or just more generally that a state adversaries will try to fully identify parties on the network?
matt_wulfeck 10y ago
This is exactly like going to the ATM and getting you bank account cleaned out... Except banks will restore your funds if it's fraudulent.
- Kinnard 10y ago
  Sometimes they will restore your funds . . . not always.
- reddytowns 10y ago
  And they'll seize your funds if they feel like it, too.
jarzonpeck 10y ago
Right or wrong; a dose of paranoia or clarity about the [ulterior] motives of the core safety warning in /r/btc Reddit. https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/ https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_saf...
- kanzure 10y ago
  "Core safety warning"? Note that bitcoin.org is not Bitcoin Core (which has a separate site, bitcoincore.org). See https://bitcoin.org/en/about-us https://bitcoin.org/en/about-us
Alupis 10y ago
Does anyone know why they suspect this particular release will be targeted by state sponsored attackers? It seems they indicate the specific 0.13.0 release will be targeted, why not the previous releases (or presumably all future releases)?
vog 10y ago
This is why I love the approach taken by Debian (and most other distros). Although they provide binary packages, they insist on building everything from source, independently from the upstream projects such as Bitcoin. Moreover, the build process itself must be able to run entirely with Free Software. And the same must hold for all dependencies. Otherwise a package can't make into their "main" distribution (just into "contrib" or "non-free", but users of these parts are warned). That way, an attacker can't simply tamper with binaries. They have to distribute the manipulates sources instead. Although that kind of attack may still be feasible, it requires a lot more openness from the attacker than just changing sources privately and distributing merely faulty binaries. This will be futher hardened by Debian's initiative to provide reproducible builds, so that if one of their many build servers is compromised, this can be detected by simply comparing hashes of the resulting binary packages produced by other build servers and/or local build of the maintainers or any curious user: https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds Speaking of Debian, unfortunately Bitcoin never made it beyond Debian/Unstable (Sid), because the Bitcoin release process appears to be incompatible with the Debian release process, especially regarding backporting security fixes, so the Debian people decided to be better safe than sorry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718272 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718272
- homero 10y ago
  Isn't it harder to hash every single file in source? There's thousands
  - vog 10y ago
    Debian simply hashes the source tarballs, then signs these hashes and some metadata, just like everybody else does. For example: http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0.11.2-1.dsc http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0.... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 3.0 (quilt) Source: bitcoin [...] Checksums-Sha256: aab2cd0c4f045970d259cf9fcee5785b43180d20ccbbedc1f90480e697696b25 5955398 bitcoin_0.11.2.orig.tar.gz e294975cd99a90c0750255303b51a9d3058a4e2e16087c6450908d7d64581772 33880 bitcoin_0.11.2-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- [...] -----END PGP SIGNATURE----- Here, bitcoin_0.11.2.orig.tar.gz is the original source tarball as downloaded from the Bitcoin project, and bitcoin_0.11.2-1.debian.tar.xz is the tarball that contains all Debian specific adjustments.
biafra 10y ago
I wonder who is keeping their secret keys in Bitcoin Core? Are people doing this? I know, I am not. I am just running it as a full node. What other attacks would be possible if nobody stored their secret keys in Bitcoin Core? Probably only attacks that required a lot of installations to be compromised.
basicplus2 10y ago
Seriously, how can anyone who knows nothing of computers use bitcoin? how can it possibly become a serious replacement currency?
- daraosn 10y ago
  It will take time... Computers, Internet and new techs in general aren't mainstream in their beginings. Do you expect it to be perfect from its inception? Even planes crashed on their first flights, and look at us now, flying everywhere.
- UweSchmidt 10y ago
  Bitcoin can not become a serious replacement currency, as no government can ever give up control over monetary policy and would rather put away lots of people than allow any threat to how things work. If you know nothing of computers you might find articles that explain Bitcoin briefly and then point you to a "wallet" that you can download and to various exchanges where you can buy Bitcoin for real money. Why not give it a shot, and "invest" a bit? You need to know quite a bit to understand the unfixable problems with computer security, and read a little to learn of the cruelty of the cryptocurrency world: no password resets, no deposit protection, no sympathy when you lose your money.
uvesten 10y ago
The key checks out, at least it's the same as for the last few releases. I imported it mid-2015, and it's still the same key.

216 points by pigeons 10y ago

If they can't protect the binaries on their web site, how can they protect the keys and fingerprints they are publishing?

grapehut 10y ago
A state sponsored attacker can reasonably easy generate a valid ssl certificate to man-in-the-middle any website, and replace it with what ever they please. However, they wouldn't be able to forge a signature if checked against the right keys
- xyzzyz 10y ago
  The point here is that how can you make sure the keys are right, if the attacker might also replace those?
- schoen 10y ago
  > A state sponsored attacker can reasonably easy generate a valid ssl certificate to man-in-the-middle any website, and replace it with what ever they please Doing this against bitcoin.org is probably taking a pretty big risk. Remember that misissued certificates represent proof of their own existence, and, if disclosed publicly, should result in an investigation of how the certificate was created. They could also choose to start using HPKP and asking browsers to report pin failures. Then a browser that has visited the legitimate site before will report to someone if it encounters an inconsistent cert in the future. That would make using a misissued cert for this site into an even bigger risk. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Reporting https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Report...
  - chrisfosterelli 10y ago
    > Doing this against bitcoin.org is probably taking a pretty big risk. Although it wasn't by hijacking the public key infrastructure, it is worth noting that China has demonstrated in the past they have no issue performing country-wide man-in-the-middle attacks against a single site [1]. Given that some CA's are Chinese, it is not that unbelievable unfortunately... [1]: http://www.pcworld.com/article/2908912/chinas-great-cannon-ddos-tool-enforces-internet-censorship.html http://www.pcworld.com/article/2908912/chinas-great-cannon-d...
    - JoshTriplett 10y ago
      True, but that attack used an HTTP resource. An HTTPS MITM attack burns a CA; browsers will remove it from their trust stores. And we're getting close to the point that it can't go undetected, either; once browsers enforce Certificate Transparency for all CAs, it'll no longer be possible to conduct an undetected MITM attack.
  - jessaustin 10y ago
    Doing this against bitcoin.org is probably taking a pretty big risk. Anyone who can escalate into stealing BTC, can afford that risk.
  - ryan-c 10y ago
    When I was looking into Chinese browsers two years ago, a number of them did not correctly validate certificates on HTTPS sites. They might not need to burn a CA. It should also be noted that HPKP will ignore issues when the cert is signed by a locally installed CA.
    - jtl999 10y ago
      It won't ignore issues for when the CA chains back to a OS preloaded one (when there is a distinction between user-added and preloaded, not sure in other case. ie Linux.) I agree somewhat more could be done on this front however if you're in a position where an adversary can add user-added CA's to your system you have bigger problems to worry about.
chrisfosterelli 10y ago
The website is vulnerable in a much larger number of ways, since it involves significantly more infrastructure which is all vulnerable to state actors. A state could generate fake certificates, physically access hosting servers, or access the internet connections the website uses. There is a much smaller attack surface for keys. If you are talking about protecting the key fingerprint they posted on the website, the idea is by publishing them now that others can note the fingerprint and warning before any malicious actor would have a chance to respond. This is also the same key they've used in the past I believe, so it can always be compared to prior releases.
- chatmasta 10y ago
  Is this a good case for distributing downloads via torrent? Or do you then face the same problem when linking to the torrent file?
  - chrisfosterelli 10y ago
    Downloading by torrent hash link is nice because it cannot be altered after release, while this isn't true with a link to a binary file on a website. However, you still have to verify the authenticity of the binary with keys if you don't trust the location you got the torrent hash from (ie, the bitcoin website). So yes, essentially the same problem I believe!
- indolering 10y ago
  It also allows them to trace any potential attacks, a state actor would need to get access to the signing machine or the private key itself.
  - placeybordeaux 10y ago
    Thats assuming that the current page wasn't altered by the attacker.
    - indolering 10y ago

kondbg 10y ago

As someone who does not follow Bitcoin news, what makes this release special enough to warrant an advance warning?

nfd 10y ago
It may not be a matter of the release being particularly special; rather, they might've been tipped off to some insider information or otherwise be aware of some information they felt it'd be best not to describe in detail right now.
- kanzure 10y ago
  Unfortunately, none of the Bitcoin developers are currently aware of any "insider info" at all. This was force-pushed by a single individual who has not been communicating with anyone about this alert.
patio11 10y ago
Maybe they're attempting to make the peer-to-peer network resistant to partitions caused by what is commonly called the Great Firewall Of China? In that case, they are not crazy to think that would draw adversarial attention. Mentioned more-than-obliquely here: https://www.reddit.com/r/Bitcoin/comments/4l564f/bitcoin_core_nonirc_meeting_summary_for_20160520/ https://www.reddit.com/r/Bitcoin/comments/4l564f/bitcoin_cor... (I have not been following this issue in close detail.)
CydeWeys 10y ago
It's nothing special about this release, it's just that this is a release. There's normally a trickle of downloads, which wouldn't be worth attacking because you'd be discovered quickly and most of your targets would be newbie users who don't have much coin worth stealing. Attack right at the moment that a new version is released, however, and you end up with your compromised binary distributed to way more people before it's discovered.

jimrandomh 10y ago

The key fingerprint mentioned is 01EA5486DE18A882D4C2684590C8019E36C2E964. (Mirroring into comments to make life difficult for anyone who wants to modify bitcoin.org's web page).

cwkoss 10y ago
Verified, this is what I'm seeing on that page as well.
- orblivion 10y ago
  You can Google the hash too.
CydeWeys 10y ago
It would be great if the core devs used their PGP keys, many of which are very highly trusted in the PGP strong set, to sign this key so that it is obviously the real deal. Right now it's only signed by two keys, Wladimir J. van der Laan's and some unknown one. Stick a bunch of other core devs on it and re-post it!
web007 10y ago
Have you done the rest of the verification necessary to say this is legitimate? * Wayback to some months ago for the download page [1] * Confirm that the content presented matches the existing download content for the 0.12.1 release (or prior) * Confirm that the content for the "0.11+ key" is the same [2] * Confirm that the signed release for the 0.12.1 content is correct and valid * Request that (full-length) key from a public GPG server If you've done all of those things, it might be a good idea for you to sign that key and push it back up to a public GPG server - that help with web-of-trust, and somewhat legitimizes the key versus some arbitrary untrusted impostor. (I have done all of these steps, and signed with my key 9BB5251DE08569D4DEEA894C85D221C11DD01DF6) [1] http://web.archive.org/web/20160109193420/https://bitcoin.org/en/download http://web.archive.org/web/20160109193420/https://bitcoin.or... [2] http://web.archive.org/web/20160109193420/https://bitcoin.org/laanwj-releases.asc http://web.archive.org/web/20160109193420/https://bitcoin.or...

akanet 10y ago

One wonders: if publishing a key fingerprint on a website in advance is considered a reasonable warning, would a torrent magnet link prove just as effective?

desdiv 10y ago
0.13.0 isn't out yet, and I don't think you can create an "empty" torrent, publish the magnet link, then update the torrent with the actual file at a later date while keeping the magnet link the same.
- akanet 10y ago
  Ah, I thought they had the release ready to go already.
- brokenmachine 10y ago
  That's correct. A Magnet link contains a hash of the file/s so it can be verified to be identical to the original during download. So you can't put the hash in there if you don't have the file yet. https://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_containing_hash_.28xt.29 https://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_conta...
  - geocar 10y ago
    No. A magnet link contains a hash of the torrent file, which is an extensible format[1]. One can simply add data to malicious torrent file until it collides with the target[2]. [1]: http://www.bittorrent.org/beps/bep_0000.html http://www.bittorrent.org/beps/bep_0000.html [2]: https://malicioussha1.github.io/ https://malicioussha1.github.io/
    - versteegen 10y ago
      You're claiming that SHA1 has been broken, but it hasn't. Have a closer look at what's actually stated at [2]. Edit: from your [1] link I see that the hashing algorithm used in a mgnet link isn't actually fixed, and MD5 is one option. So yeah, I guess you actually can't trust the immutability of a magnet link without checking it's doesn't contain urn:md5 or urn:kzhash.

pigeons 10y ago

I feel irresponsible for submitting this since I'm told no one but the poster knows anything about this and this did not go through the normal checkin process for bitcoin.org. Waiting, we'll see...

Taek 10y ago
Vigilance around binaries is a good thing anyway. I hope though that this does not damage relations with the Chinese community, as singling them out without good cause is unjust.
- MichaelGG 10y ago
  >without good cause China has been well known to MITM traffic. No one should be offended by pointing this out.
  - Buge 10y ago
    Yeah, and injecting Javascript malware. I haven't heard of them MITMing HTTPS though.
    - puetzk 10y ago
      http://ncjolt.org/googles-distrust-of-chinese-digital-certificates/ http://ncjolt.org/googles-distrust-of-chinese-digital-certif... CNNIC was the root of trust for a breach involving false certificates for gmail. They claim it was an accident. It might have been. It might not have been.
pmorici 10y ago
I'd say it's quite possible that someone is just trying to spread FUD to distract from the emerging plans to fork Bitcoin to bigger blocks that have been materializing in the past couple days.

orblivion 10y ago

Anybody know how this affects the Bitcoin PPA?

kanzure 10y ago
Do not use "the bitcoin PPA". Launchpad compiles this on their own infrastructure outside of the gitian build process. If, for some insane reason, if you must use "the bitcoin PPA", always check hashes, always verify the binaries are correct, and always check signatures regarding those particular hashes. edit: livejournal -> launchpad
- orblivion 10y ago
  The PPA seems to be the recommended Ubuntu install instruction on bitcoin.org: https://bitcoin.org/en/download https://bitcoin.org/en/download Aren't all of Ubuntu's packages built on launchpad? It's interesting that you don't trust launchpad, should I not trust my OS either? And as far as checking signatures, that's what apt does automatically anyway, as I understand. I know people like Moxie insist that it's only acceptable to have the (at least) software's author sign the software. Well, personally I'd rather trust a larger organization with more reputation to lose. (Ideally I'd have both, of course, when we get to deterministic builds.) edit: Oh, deterministic builds is what gitian is. Okay I see your point :-) But still, why trust your OS at that point?
  - kanzure 10y ago
    Yes, deterministic debian is a good idea and we should make that happen.
    - orblivion 10y ago
      In the meantime, do you recommend against PPAs in general, or just for specific sensitive things like Bitcoin?
      - kanzure 10y ago

jvehent 10y ago

bitcoin.org does not implement HPKP. Any government that controls a CA can generate its own cert for bitcoin.org, hijack the site's IP and replace this page with their own fingerprint.

jlgaddis 10y ago
And China has a root CA under their control. I'm on my iPad at the moment so I can't provide the fingerprints of it right now, but I remember "un-trusting it" on all of my machines a long while back.
- l2dy 10y ago
  I believe there are two of them: "CNNIC Root" and "China Internet Network Information Center EV Certificates Root".
- indolering 10y ago
  As does anyone with enough money to purchase a certificate authority or crack a certificate authorities servers.
- barsonme 10y ago
  Also this: https://github.com/chengr28/RevokeChinaCerts/ https://github.com/chengr28/RevokeChinaCerts/
- mynewtb 10y ago
  And the US, host of malicious entities like the CIA and NSA, has several root CA's under their control.
  - jlgaddis 10y ago
    Yes, of course. There's something like, what, around 400 root CAs, I think? I mentioned the .cn government (and their root CA(s)) because the article mentioned the .cn government, specifically, and the parent comment mentioned "any government that controls a CA". Obviously, any government with a) control over a root CA and b) control over their entire country's Internet access could carry this out. The article we're commenting, however, called out .cn by name.

kanzure 10y ago

So far, none of the others I have pinged about this has any info as to its veracity or background. Unlike most contributions to bitcoin.org, this one was pushed to the master branch without a corresponding pull request (a mechanism used to solicit review and feedback from others). https://github.com/bitcoin-dot-org/bitcoin.org/commit/5e0fd5292c936324660c680e4e99506da659c9fb https://github.com/bitcoin-dot-org/bitcoin.org/commit/5e0fd5... I suggest skepticism. We should be cautious of anyone skipping peer review processes, even for security incidents. Poor handling of these situations can lead to unintentional panic where panic of any kind is unhelpful to resolving issues. However, everyone should always be encouraged to check the signatures regardless of alerts, of course. Multiple signatures should always be checked, and not just Wladimir's signature. Use the gitian signatures repository to get other signatures, and always verify public key and signature data through multiple independent channels. gitian signatures repository: https://github.com/bitcoin-core/gitian.sigs https://github.com/bitcoin-core/gitian.sigs GPG build verification steps: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#verify-other-gitian-builders-signatures-to-your-own-optional https://github.com/bitcoin/bitcoin/blob/master/doc/release-p... gitian build steps: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-bu... gnupg CVE-2016-6316 from today https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/0003... Also, don't use gpg short ids. Always verify fingerprints. There are gpg short id matching keys floating around for some Bitcoin developers - for example, http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2346C9A6 http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint... check out the revoked key. ( This reply is x-posted from https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary... )

wildchild 10y ago

No worries they want to drive price down.

ipsin 10y ago

Is the concern here specifically related to the NSA Shadow Brokers hack (where they're supposedly auctioning the goods for bitcoin), or just more generally that a state adversaries will try to fully identify parties on the network?

matt_wulfeck 10y ago

This is exactly like going to the ATM and getting you bank account cleaned out... Except banks will restore your funds if it's fraudulent.

Kinnard 10y ago
Sometimes they will restore your funds . . . not always.
reddytowns 10y ago
And they'll seize your funds if they feel like it, too.

jarzonpeck 10y ago

Right or wrong; a dose of paranoia or clarity about the [ulterior] motives of the core safety warning in /r/btc Reddit. https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/ https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_saf...

kanzure 10y ago
"Core safety warning"? Note that bitcoin.org is not Bitcoin Core (which has a separate site, bitcoincore.org). See https://bitcoin.org/en/about-us https://bitcoin.org/en/about-us

Alupis 10y ago

Does anyone know why they suspect this particular release will be targeted by state sponsored attackers? It seems they indicate the specific 0.13.0 release will be targeted, why not the previous releases (or presumably all future releases)?

vog 10y ago

This is why I love the approach taken by Debian (and most other distros). Although they provide binary packages, they insist on building everything from source, independently from the upstream projects such as Bitcoin. Moreover, the build process itself must be able to run entirely with Free Software. And the same must hold for all dependencies. Otherwise a package can't make into their "main" distribution (just into "contrib" or "non-free", but users of these parts are warned). That way, an attacker can't simply tamper with binaries. They have to distribute the manipulates sources instead. Although that kind of attack may still be feasible, it requires a lot more openness from the attacker than just changing sources privately and distributing merely faulty binaries. This will be futher hardened by Debian's initiative to provide reproducible builds, so that if one of their many build servers is compromised, this can be detected by simply comparing hashes of the resulting binary packages produced by other build servers and/or local build of the maintainers or any curious user: https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds Speaking of Debian, unfortunately Bitcoin never made it beyond Debian/Unstable (Sid), because the Bitcoin release process appears to be incompatible with the Debian release process, especially regarding backporting security fixes, so the Debian people decided to be better safe than sorry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718272 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718272

homero 10y ago
Isn't it harder to hash every single file in source? There's thousands
- vog 10y ago
  Debian simply hashes the source tarballs, then signs these hashes and some metadata, just like everybody else does. For example: http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0.11.2-1.dsc http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0.... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 3.0 (quilt) Source: bitcoin [...] Checksums-Sha256: aab2cd0c4f045970d259cf9fcee5785b43180d20ccbbedc1f90480e697696b25 5955398 bitcoin_0.11.2.orig.tar.gz e294975cd99a90c0750255303b51a9d3058a4e2e16087c6450908d7d64581772 33880 bitcoin_0.11.2-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- [...] -----END PGP SIGNATURE----- Here, bitcoin_0.11.2.orig.tar.gz is the original source tarball as downloaded from the Bitcoin project, and bitcoin_0.11.2-1.debian.tar.xz is the tarball that contains all Debian specific adjustments.

biafra 10y ago

I wonder who is keeping their secret keys in Bitcoin Core? Are people doing this? I know, I am not. I am just running it as a full node. What other attacks would be possible if nobody stored their secret keys in Bitcoin Core? Probably only attacks that required a lot of installations to be compromised.

basicplus2 10y ago

Seriously, how can anyone who knows nothing of computers use bitcoin? how can it possibly become a serious replacement currency?

daraosn 10y ago
It will take time... Computers, Internet and new techs in general aren't mainstream in their beginings. Do you expect it to be perfect from its inception? Even planes crashed on their first flights, and look at us now, flying everywhere.
UweSchmidt 10y ago
Bitcoin can not become a serious replacement currency, as no government can ever give up control over monetary policy and would rather put away lots of people than allow any threat to how things work. If you know nothing of computers you might find articles that explain Bitcoin briefly and then point you to a "wallet" that you can download and to various exchanges where you can buy Bitcoin for real money. Why not give it a shot, and "invest" a bit? You need to know quite a bit to understand the unfixable problems with computer security, and read a little to learn of the cruelty of the cryptocurrency world: no password resets, no deposit protection, no sympathy when you lose your money.

uvesten 10y ago

The key checks out, at least it's the same as for the last few releases. I imported it mid-2015, and it's still the same key.