encryption method against man in the middle attack

Question

Let's say there are 3 computers: Alice, Bob, Carol. Carol is network provider, so everything from Alice to Bob and vice versa passes through Carol. Carol can modify messages between Alice and Bob. Is there any algorithm or method for secure communication between Alice and Bob, even if Carol can modify packages? For Diffie-Hellman I found this:

Roughly speaking, the basic idea is as follows. Prior to execution of the protocol, the two parties Alice and Bob each obtain a public/private key pair and a certificate for the public key. During the protocol, Alice computes a signature on certain messages, covering the public value ga mod p. Bob proceeds in a similar way. Even though Carol is still able to intercept messages between Alice and Bob, she cannot forge signatures without Alice's private key and Bob's private key. Hence, the enhanced protocol defeats the man-in-the-middle attack.

Can anyone explain with example?

Edit: A is client, and B is server, A uses login/password to authenticate.

Answer 1

You need a definition. Namely, what is "Bob" in Alice's view ? If "Bob" is "whoever responds" then Carol would make a nice Bob -- in that case, there is no real attack, just Alice talking to "someone" who happens to be Carol.

If there is a definite notion of Bobness that Alice can use, then there are algorithms which build on that. That's how SSL works. Imagine that you are Alice, Bob is a Web site that you know by name (e.g. "www.paypal.com"), and Carol is your Evil ISP. You do not want to talk to just anybody, you want to talk to a specific Bob/server that has a name. Public key certificates can use signatures to give you some guarantee over the binding between the name ("Bob", aka "www.paypal.com") and a public key: the guarantee provided by the whole system is that a given public key is really "owned" by an entity who bears the name "www.paypal.com", where "owning" means "having exclusive control of the corresponding private key", and in a way that Carol cannot obtain a similar guarantee.

Once there is a known server's public key, the key exchange can be protected against MitM. Again, see how it is done with SSL.

In the case of X.509 certificates, Alice must have an a priori knowledge of a root certificate authority public key (here "trust anchor"). For another model, consider SSH. Here, we assume that Alice could establish, at some point, a Carol-less connection to Bob (or a connection that Carol did not bother to alter). Then, Alice remembers Bob's key, and uses it again for all subsequent connections. That's how SSH usually works: for the first connection, the client requests explicit user confirmation, then stores the public key in Alice's .ssh/known_hosts file. Ideally, for the first confirmation, Alice would verify with some out-of-band mechanism the server's public key (its fingerprint) before accepting it the first time (e.g. by making a phone call to the server sysadmin, and checking with him the key fingerprint).

Answer 2

Possible answer: when you communicated with through secured connection such as SSH, SCP, SFTP, and the likes, and as long your linux box (client) is not compromised, you basically are safe from "man in the middle" attack. TLS/SSL protocol is considered to be secure. Self-signed certificate if you signed it yourself, it's safe, too.

See also https://security.stackexchange.com/questions/6437/how-would-one-fully-protect-himself-against-man-in-the-middle-attacks