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

Closed
i-rme opened this Issue Aug 18, 2016 · 8 comments

Comments

Projects
None yet
7 participants
Contributor

i-rme commented Aug 18, 2016

At present, the Bitcoin.org domain sends this header
Strict-Transport-Security: max-age=31536000

This 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; preload

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

Contributor

btcdrak commented Aug 22, 2016 edited

ACK this is essential.

Here's another explanation https://www.troyhunt.com/understanding-http-strict-transport/

Contributor

jonasschnelli commented Aug 24, 2016

ACK (seems to be important).

Contributor

laanwj commented Aug 24, 2016

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.

Contributor

MarcoFalke commented Aug 24, 2016

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.

Contributor

theymos commented Aug 24, 2016

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

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.

Contributor

Cobra-Bitcoin commented Aug 29, 2016 edited

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.

Contributor

btcdrak commented Aug 29, 2016

@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".

Contributor

Cobra-Bitcoin commented Oct 17, 2016

It's preloaded now. Thanks everyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment