Well, there are many options other than SSL to prevent a man in the middle attack, but most all of them have a similar cryptographic basis. Fundamentally, to ensure that a communication can't be attacked by a man in the middle you must be able to prove that a) both parties can validate the other and b) that no other party can monitor the communication.
Both of these are most commonly accomplished through a shared secret. Asymmetric cryptographic operations can also be used where both parties have a trusted public key for the other, however this is much more difficult (computationally) than exchanging a shared secret and then using that.
The shared secret can either be pre-shared, such as in the case of an encrypted wifi network, or it can be negotiated through an authentication process. For example, with SSL, the server validates itself to the client through signing the public key, the client then establishes a shared secret with the server by using the server's trusted certificate and the server then validates the client through a traditional login (or possibly a client certificate in rare cases.)
This general process is not unique to SSL, but the basic steps of verifying identity of one or both parties and establishing a secure communications key is the critical bits. If, however, the root of the trust for that certificate was compromised, it would be possible for someone to man in the middle since they could pretend to be the server and open their own connection with the server and their own connection with the client.
In the event of a private key leaking, the certificate should be revoked via a revocation list. This is generally published by a CA and is included as part of the signed certificate. As a condition of validating the validity of the certificate, the revocation list should be checked for validity.