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