Serve bitcoin.org over plain HTTP

[luke-jr]

TLS should not be mandatory.

[saivann]

Why not serving everything over SSL? If there's no redirection in place, it is likely that https: won't be used very much, because all previous links on the Web use http: .

[luke-jr]

Not everything supports SSL. And it's often easier to failover to HTTP when the CA is not trusted, than to ignore the CA being untrusted.

[gmaxwell]

@luke-jr I've spent several minutes trying to figure out what you mean by "easier to failover to HTTP when the CA is not trusted, than to ignore the CA being untrusted".

If HTTP use isn't blocked through the use of HSTS then HTTPS is completely worthless because an attacker can just block HTTPS to force the use of HTTP.

[luke-jr]

I mean browsers have been making it harder and harder to ignore an untrusted CA (and just use the HTTPS connection with the understanding it may be unsafe); with HSTS, it's even impossible. So, people who don't trust (or don't have SSL support) are left out entirely unless HTTP is also available.

The "attacker" being able to force the use of HTTP is not really a vulnerability.

[saivann]

It was in my plans to enable HSTS, although to my understanding, HTTPS is still secure when the user uses the HTTPS url from the start (which will happen often if we redirect to it).

IMHO, the drawbacks of not redirecting to HTTPS appear higher than the benefits of keeping HTTP compatibility. While I generally agree with making bitcoin.org as much accessible as possible, in this case I don't see a measurable number of visitors who would be turned out. Even the most rudimentary browser supports HTTPS and lets the user access an untrusted website after displaying a warning box.

Serving duplicate content on different ports also has drawbacks when it comes to SEO and not redirecting to HTTPS means nobody will use SSL (and MITM attacks will be easier). Electrum, Armory, MultiBit all choosed to use SSL over time, and I think if we don't, we would keep getting repeated requests to secure the website like before.

[gmaxwell]

@saivann wrt my secure commne.t HTTPS does very little good if the users will happily use http when https does not work, as anyone who could tamper with http has equal power to simply block https.

We have proof that tens thousands (hundreds of thousands?) of users will use http alone for this site when https isn't available. So I think that without (eventually) having HSTS the HTTPS is a generally a waste of time for us.

[saivann]

@gmaxwell Sure, I've just tested HSTS on the server and it was pretty straightfoward to setup. I'm just saying that increasing the number of direct HTTPS access is also a required part of the solution.

[luke-jr]

@saivann libcurl is often compiled without SSL support (eg, in OpenWrt). Some users may be security-conscious and choose which CAs to trust, and might not include the one we happen to use - while uncommon, I don't think we should discourage users who are better in their security practices than others.

"Even the most rudimentary browser ... lets the user access an untrusted website after displaying a warning box.", but NOT with HSTS.

Electrum, Armory, and MultiBit still do releases based on a trusted party, whereas Bitcoin Core is ahead of this by using multiple PGP signatures. Quite a difference. Degrading Bitcoin Core downloads so that people must trust a single person is a regression IMO.

[mikehearn]

If your tools don't support SSL, get better tools.

If you don't trust the CA then mentally cross out the padlock icon in your browser and assume your adversary is reading and modifying all your traffic regardless of the SSL.

Let's close this issue - it's bizarre.