Hacker News Reader

Comment by jjnoakes | Hacker News Reader

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

View on HN

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.

Is this a good case for distributing downloads via torrent? Or do you then face the same problem when linking to the torrent file?

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!

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.

Thats assuming that the current page wasn't altered by the attacker.

Which is why you check it using multiple VPNs and compare it to the internet archive.

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

The point here is that how can you make sure the keys are right, if the attacker might also replace those?

> 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#Report...

> 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-d...

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.

Doing this against bitcoin.org is probably taking a pretty big risk.

Anyone who can escalate into stealing BTC, can afford that risk.

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.

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.

Reply on news.ycombinator.com