Point is, I should not be able to access a plaintext version of a website hosting such cryptographically crucial software/information.
It's obvious why it can be a grand target for Man in the Middle, defacement and worst of all integrity attacks. Apart from preventing many of the latter, implementing HSTS could have really mitigated the problem. Anyone who had already visited the site wouldn't see the defaced page. Furthermore, they could get added to an STS preloaded list[1], making the attack invisible to anyone using a modern browser.
If you are interested, the Wikipedia page[2] does a fair job at explaining more about why HSTS is needed.
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.
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.
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.
I'd never heard of HSTS, but after reading that wiki page I find myself wondering along with Peter how much good it could ever do, in general, that a 301 to https doesn't already do. Sure it's good for a naive user who has already been to the correct uncompromised site. Sure it's good for a naive user visiting a popular Chrome-approved site with Chrome for the first time. I don't see how these two minor wins (especially for a site like that under discussion) make it worth the effort.
Which is, to say, 99.99% of people. Noone types "https://" or "http://"; 99% of people don't even know what https means. Us developers should know better and protect our users. It's our responsibility to make sure the default is secure.
SSLStrip does not work on valid HTTPS requests. If you request an HTTPS page, it can not be subverted into HTTP. If it could, HTTPS would be pointless. So, yes, HSTS is not required for a valid HTTPS request. This is not some semantic argument, or some sort of side channel attack crap. HSTS is not necessary for HTTPS requests, period.
