The failure is not in the protocol, it is in the people. Or, arguably, in the tools, who should handle matters that are too technical for human users to do correctly.
The SSL protocol states how things go, and that the connection will be secure, notably against Man-in-the-Middle attacks:
- The negotiation of a shared secret is secure: the negotiated
secret is unavailable to eavesdroppers, and for any authenticated
connection the secret cannot be obtained, even by an attacker who
can place himself in the middle of the connection.
But this holds only if the protocol is really followed to its full extent, and, in particular, if the validation of the server public key is not "shortcut".
Thus, there is nothing to change in the protocol. When tools don't implement the protocol properly, then the fault usually lies in the tools, not the protocol.
We could argue that if browsers still allow for bypassing the "bad certificate" warning (though that warning has increased in reddish scariness over the years), then this might be an indication that the protocol assumptions are not realistically tenable. Namely, requiring that all Web servers have a SSL certificate that client browsers can validate might be a bit too much to ask for. But, honestly, security has to start somewhere. Cryptography does not create trust, it transfers trust. You cannot have a protocol which guarantees that the client will always talk to the "right" server without having, at least, a definite notion of what "right" means in that context.
If phishing or MitM attacks with a fake server certificate, clicked through by the user, become too prevalent, I expect browser vendors to actually remove the bypass altogether, and enforce strict X.509 validation. We'll see in a few years.