Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Enable HSTS Preload in bitcoin.org domain to avoid MITM attacks #1343
Comments
|
ACK this is essential. Here's another explanation https://www.troyhunt.com/understanding-http-strict-transport/ |
|
ACK (seems to be important). |
|
Yes, it makes sense to do this, to make sure first-time users get redirected to the https site immediately, without SECONDDATE and its international friends getting a shot at it. |
|
Disabling https completely to dowload the Bitcoin Core binaries could, however, raise awareness that SSL is not enough to assert that the retrieved data is authentic. SSL relies on a central CA not to be compromised and even if HSTS was enabled, anyone with access to the server could easily replace some of the content for just some users. (E.g. based on their location or IP address, so the attack would be harder to notice) Though, I doubt the majority of users will go through the effort to fetch the signed hashes of the deterministic build process and compare them in addition to verifying the signatures properly (WOT)... But HSTS doesn't make it any worse for those that already verify the signatures, so I am not against enabling it. |
Yeah, so IMO HTTPS is still far better than HTTP even though it's not exactly the strongest security. With HSTS preload there's some risk of every single CA blacklisting bitcoin.org in order to deny service, but I've never heard of this happening before, so it seems unlikely. |
|
I made the necessary changes on the web server and submitted to the preload list. We just have to wait now until it goes live on the next release of browsers. The main issue with HTTPS is that it tricks users who aren't tech savvy into assuming the site is 100% "safe", but as Marco pointed out, the server itself could be compromised and acting maliciously. The green padlock icon that browsers show comes across as too reassuring. It makes it a lot easier for an attacker, because during an attack, the reassuring green padlock is being shown while the user is downloading whatever evil_binaries.exe the attacker is serving them. We probably won't ever get the majority of users to verify the signatures though, but we'll be OK so long as we get a representative sample of them to do it. |
|
@Cobra-Bitcoin Thank you. Regarding verification, while I remain pessimistic about getting the majority of users verifying binaries, Bitcoin Core are working on a user-friendly verification tool which should reduce the friction somewhat. You might want to consider a "popup" for the download button. Clicking download reveals a hidden with a reminder to verify downloads and has the actual download link under the warning. Maybe that could be hidden until they tick "Yes".
|
|
It's preloaded now. Thanks everyone. |
i-rme commentedAug 18, 2016
At present, the Bitcoin.org domain sends this header
Strict-Transport-Security: max-age=31536000This header is also known as HSTS, it tells the browser to only connect using HTTPS for the next 365 days.
The problem appears when the client is visiting bitcoin.org for the first time (or in incognito mode, or has deleted cache, etc.) The browser does not know that has to use HTTPS to browse to bitcoin.org so when the user types the domain in his browser he will be connecting to http://bitcoin.org instead of https://bitcoin.org. If the network is being attacked he will be downloading malware instead of Bitcoin software.
How to fix it:
Add the includeSubDomains and preload directive to the header sent.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadThen just submit bitcoin.org domain to the HSTS Preload list in Chrome, Firefox and IE. This can be done easily just by clicking this link:
https://hstspreload.appspot.com/?domain=bitcoin.org
Once submitted the next releases of the browsers will include bitcoin.org in the HSTS Preload list and no one could load bitcoin.org via HTTP again.
As an example, bitcoin-related websites already using HSTS preloading include Coinbase, Coinapult, Bitgo, Localbitcoins, bitcoin.de, blockchain.info, GDAX and Multibit.