[peterwwillis]

Or maybe they should have plaintext access, because then they can get the software if they don't have an SSL-enabled HTTP client, and they can compare the digital signature of the sources later via 3rd parties.

But this is all crap, really. OpenSSL is a library distributed across tens of thousands of independent providers all over the internet. Nobody needs to get it from the main site, and even if they do, there's a multitude of ways to tell if it's the real deal or not. If you know what OpenSSL is, you can type in "https" and be totally secure without HSTS. Even if you needed HSTS (which you don't), who's going to the OpenSSL.org website time after time that HSTS would even be useful?

People make way too big a deal over half-baked countermeasures that don't apply to every case. You find me the person who's downloading vanilla OpenSSL libraries from the main site over multiple visits and is at risk of a client-side MITM and not verifying their sources, and i'll show you someone who's going to get owned even without a MITM.

[dionyziz]

You seem to have completely missed the fact that HSTS can be combined with an STS preloaded list, to which the previous comment author also gave you a reference to read. HSTS is TOFU (trust-on-first-use) by default, but the TOFU portion can be upgraded to a full PKI-based authentication mechanism just fine using preloaded lists, which doesn't require any previous visits whatsoever.

Furthermore, it's just embarrassing to see such attacks on these high-profile sites. If they can't defend their site (even for users who don't type "https://"), who is to say their library is secure? These kinds of attacks threaten the confidence we have on our fundamental cryptographic building blocks and should be avoided.

[peterwwillis]

In reverse:

1. These attacks don't bear at all on cryptographic building blocks, because any script kiddie can brute force a login or fuzz an input, etc. Has nothing to do with crypto at all. Has nothing to do with their code at all. Completely different systems with completely different attacks with incredibly different requirements... it's worlds apart. There is nothing about defacing a website or even MITM that could ever be compared to breaking a crypto library.

2. HSTS is quite a bit different from the PKI of TLS. That said, what you are basically saying is "HSTS is the same thing as HTTPS when you add the URL to the browser's STS whitelist". (Which could be avoided altogether if you just type "https")

So what your argument really boils down to is: a crypto library is worthless because we really need to use HSTS because OpenSSL.org users are too stupid to type "https".

Not only is this inaccurate and nonsensical, it's just a crappy security model. Now I have to manage HSTS exactly the same way TLS certs are managed and basically reproduce one protocol into a pseudo-protocol and juggle both, keeping things like RFC 6797 in mind. Suddenly the complexity's gone up enormously over time, only to prevent MITM on the client, and we don't even consider whether or not the content was compromised before the connection of the client to the server.

Even if the server is hacked, you still have absolutely no guarantee if the content was modified, because you're not verifying the content once you download it. But sure. Let's freak out about the possibility of a one-sided MITM to the client over HTTP (which every idiot knows is not secure by design), because that's clearly the most important or likely attack to be worried about right now.