Terminology: a secure channel is a communication channel that is protected against man-in-the-middle attacks and eavesdropping. Encryption alone does not make a secure channel. The simple way to establish a secure channel is to use SSL/TLS. but there are subtleties.
Encrypting the traffic is only part of the protection against man-in-the-middle attacks. This prevents the attacker from decoding the traffic, because he doesn't know the decryption key. This also prevents the attacker from injecting arbitrary traffic, because he doesn't know the encryption key.
With only encryption, the man-in-the-middle can inject some traffic by coming up with some ciphertext. He might not know what the plaintext is, but that can still cause trouble — the recipient is getting garbled data, which could even trigger a parser bug. A secure channel provides not only encryption, but authentication — a verification that the data comes from the legitimate source.
If the communication protocol is based on packet, each packet must have a tag that indicates who sent it (so that the attacker can't send traffic from one party back to itself) and some kind of sequence number (so that the attacker can't resend an old packet, which may now have a different effect).
Of course, if the attacker can suppress traffic in addition to listening and injecting, the attacker can disrupt the communication by cutting it off altogether, reordering packets, etc. Reordering packets can be detected (and the packets reordered or discarded) by properly using sequence numbers to authenticate the communication (which is stronger than authenticating each individual packet). No amount of cryptography will remove the attacker's ability to block all traffic, if he can delete packets. You need physical means: armed couriers, radio transmitters that are stronger than the adversary's jammers, …
Encryption might not always ensure that the communication remains confidential. The communication may allow side channels. In particular, the size and timing of packets may be revealing. For example:
- If on 5 June 1944 the BBC had suddenly transmitted a flurry of coded messages, that would have indicated that something was afoot, even if the messages had been undecodable. Remedy: send coded messages all the time, and if you have nothing to send, send random messages that are indistinguishable from useful messages.
- The size of the message may be an indication. For example, if military orders are sent to a rnpwbhm instead of a mcouzjooyb, you would know that the scope is important enough to involve a captain rather than a lieutenant, even if you wouldn't have been able to decrypt the rank. Remedy: use fixed-length codes for related concepts; dually, randomly vary the length of potentially-recognizable terms (e.g. through variant spellings of proper names, or more systematically append random-length garbage). (Both the attack and the remedy I cite here are from WWII histories, though I don't have the reference at hand.)
- Voice traffic is particularly vulnerable to reconstruction because it is typically compressed and sent in real time. The rhythm of packets alone can be enough to reconstruct speech in lab conditions. Remedy: compress less and accept more lag, for example send a fixed-size packet every N milliseconds.
Another difficulty with protecting against man-in-the-middle attacks is initiating the communication. With a pre-shared key, this is not a problem, but if the two parties don't know each other beforehand, the attacker could be a direct man-in-the-middle: when Alice tries to establish a channel with Bob, Eve intercepts all packets and lets Alice establish a channel with her, then she establishes a channel with Bob, and relays traffic or not as she pleases. This is why SSL requires a certificate verification: the client verifies that the channel it's setting up is to the desired server (and, optionally, the server performs the symmetric verification).
