tl;dr HSTS thwarts sslstrip, HPKP thwarts CAs hijacking, but neither is actually foolproof. read below for my solution.

The sslstrip problem seems impossible to make secure using the existing web. The inherent problem is that the web allows both insecure and secure connections; if https doesn't work, people [or browsers] will just try http, and there is no way to determine if a site is supposed to use https or not. (It would be nice if we required a 'ssl.' subdomain be used for https-only connections, but nobody seems to like that suggestion, and there's some scaling issues)

I think the most permanent, flexible solution for all these problems is twofold: one, a protocol which makes secure connections mandatory, and two, mandatory multiple identity verification.

Unlike SPDY, which allows non-SSL connections and used to allow compressed headers to be encrypted, another protocol (or layer?) should be introduced that makes it impossible to have a connection which isn't encrypted and signed by a CA (no self-signed certs allowed). This would ensure that no communication with a host over this protocol would be of questionable integrity. Users could decide for themselves that if this connection doesn't work, they simply won't try to contact the host via lesser means (like https).

Going further, it seems to me there's two logical ways to prevent a hijacked CA from feeding you spoofed certs on the initial connection: Convergence, and/or multiple CA verification.

Convergence stops the initial-connection attack by requiring multiple independent parties agree on the data you're getting. The hijacker would have to also hijack all the Convergence peers for this to succeed, which is effectively very difficult. But this requires a highly available public network of peers to work, which is problematic in many cases.

Instead, one could provide a certificate chain on the initial connection to the destination host with the same certificate signed by multiple independent CAs. IMO this is a better solution than Convergence because it doesn't require the consensus of a live public network or multiple hosts, but does still provide a guarantee of authenticity verified by multiple independent parties, which would again be very difficult to hijack all at once.

To provide this second method you'd need to do several things: One, send the same CSR to multiple CAs and collect the certs (this already works). Two, require a protocol identifier that mandates only secured connections (something other than http/https, so users don't get confused). Three, mandate no self-signed certs. Four, require a certain minimum 'assurance index' be reached by using a set of heuristics to classify the certs received and determine if they're from enough CAs (or CAs different enough from each other, like one from the UK, one from Iran and one from Brazil). Five, make sure all the certs match and are all signed by the same origin host key.

Then all you'd have to do as a user is type in 'rfsp://mybank.com' and your connection would either succeed securely the first time, or irreversibly fail. The server admin would just tack on a bunch of different certs from different CAs into the chain and provide the new encryption layer, under which HTTP (or whatever) would pass.