The problem with it is that SSL/TLS is designed and intended to protect commerce. The attackers that commerce cares about† aren't targeted. If they can't sniff someone's session because they already established a trusted pairing with their bank, so be it! They'll just wait for the next person to connect. They will obviously get some percentage of user sessions that way, either from first connections or because people changed computers or reinstalled their browser or deleted files or what-have-you.
These are connections the attackers get above and beyond the stuff they already get by owning up machines. Which they'll also be able to do more of, because the same problem will happen with software update systems.
The current hardwired selection of CAs we have is bad, is a flaw in SSL/TLS/HTTPS even, but it's not so bad that we continuously lose X% of all connections to passive attackers.
† and that you should care about if you value the ability to run businesses on the Internet
Or, Tyler Close's 'YURL'/httpsy scheme for making introduction/bootstrap the important step, rather than a CA/PKI lookup:
I'm no expert but I think the solution is already here in the form of http://convergence.io/ http://perspectives-project.org/ and other, similar projects. If each of us could have several trusted notaries (including an ability to run one) taking a look at every ssl certificate we accept by comparing it to what others are seeing, what is served in the dns records for requested domain, whether its integrity is secured with dnssec, what was presented on last connection, and whether it's signed by a trusted CA, we would have a pretty safe system, unshaken by the failure of any single entity.
Convergence is already doing a lot of it, unfortunately, last time I checked it was still breaking on SNI. But that's a minor problem with a particular plugin, the approach itself is, again in my non-expert opinion, great.
Mostly. No matter much you trim your certificate chain, there's nothing preventing Google/your bank/Amazon/etc from sharing their private key with, say, Uncle Sam. However, the backdoor admin access that the gov't gets to sites like TwitterFace and Gmail probably makes that a pointless effort.
Confidentiality/Authenticity are pretty much impossible to guarantee unless you control everything on both ends.
I mean yes, if you're paranoid enough you probably should build an underground bunker in the mountains and grow your food, but objectively there is a huge security difference between whatever shenanigans a trusted partner may be up to and a large body of auto-trusted with potentially leak able-to-who-knows-where subcerts.
¹ (remember, even if you have a cert with a specific CA, nothing technically prevents a cert from being signed with another CA's certificate).
This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count. Fingerprints would be submitted to a public service that accumulates submissions from different users, identified by the same public key used to sign the submissions. Trustworthiness would be weighted based on the history and age of the users' submissions: someone who has used the same public key and submitted fingerprints for five years is likely to be a real user that you can trust instead of a bot that generates new identities in order to submit false fingerprints to launch a MITM. There are numerous ways to implement this.
One positive thing would be to bring the same attention to trustworthiness to people's minds that they must employ in "real" life as well, i.e. offline. A website that's never fraudulent or genuine (unless you got it in writing) but shades of trust more reflects the interactions we encounter in real life (can I trust this guy because my friend said he's ok?).