Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
@torateff you should mark Thomas Pornin's answer as right answer. –  Rahul Gautam Oct 12 '12 at 6:37
add comment

2 Answers

up vote 5 down vote accepted

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).

share|improve this answer
    
In my case Alice is me, Bob - is skype server, Carol is my ISP, I wanted to know can my ISP read my messages. Beside skype, if I build my own instant messaging service, what steps must I do to keep secure communication? –  torayeff Oct 7 '12 at 16:53
add comment

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 How would one fully protect himself against man in the middle-attacks?

share|improve this answer
    
You are safe from man-in-the-middle attacks if you check the server key, i.e. don't click through SSL warnings with HTTPS, check the server's public key fingerprint with SSH. –  Gilles Oct 7 '12 at 20:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.