The conventional wisdom is that it's not possible to detect MITM attacks other than by using some trusted path to validate the credentials from the other end. But that's not quite true. When an attacker decrypts with one key and re-encrypts with another, the encrypted bit stream changes. Both ends now have different encrypted bits. If they can somehow compare them, a MITM attack can be detected.
One early secure telephone unit displayed a 2-digit number derived from the beginning crypto bits. Users were supposed to confirm, by voice, that both units showed the same number. An attacker would have to break into the voice stream and substitute voice words in a matching voice to prevent that detection. This illustrates what's possible. It's possible to force a MITM attacker to do considerable work (perhaps an arbitrarily large amount of work) to prevent both ends from comparing notes on what crypto bits they have. More than that, the endpoints can force the attacker to have to construct an arbitrarily complex lie in the form of impersonation of content. David Chaum (of DigiCash fame) claims to have developed a way to detect MITM attacks along these lines. See U.S. Patent Application #*20060218636.* The USPTO rejected the patent application, because of prior art from Microsoft (U.S. Patent # 7,475,421) for "Automatic Re-Authentication", which is about recovering disconnected Microsoft Terminal Server sessions securely and is limited to re-connection. So Chaum's approach seems to be unencumbered by patents. However, his explanation is almost incomprehensible. There's a thesis that explains it, though. http://www.cisa.umbc.edu/papers/theses/newton-thesis-2010.pdf Even that is heavy going. Here's a simple explanation of the concept. if both ends can compare some of their crypto bits, they can detect a naive MITM attack that's decrypting and re-encrypting at the transport level. A smarter MITM attack would detect and rewrite that exchange of info, even if it occurred at a higher protocol level, like HTTP. However, the effort required by the MITM attacker can be made very large, and the MITM attacker can be forced to introduce delay. An example approach would be to send an HTML or XML document which contains an item showing the N crypto bits that both ends should be seeing. Wrap the entire document with an item which has a cryptographic hash of the entire document, and send the hash BEFORE sending the document content. If the attacker just sends the HTML/XML through unchanged, the attack will be detected. If they change the item containing the N crypto bits, the hash will be wrong and the attack will be detected. If they generate a fake document with suitable crypto bits and hash, they have to do so before they've seen the entire content of the actual document. If they buffer up the entire document so they can modify the document, they introduce delay equal to the transmission time for the entire document. It should be possible to detect that delay. This is merely an illustration. There's probably a better approach. The point is that it is possible to detect MITM attacks which involve re-encryption with a different key. Is there a way in OpenSSL to retrieve, at the application level, a small sample of the encrypted bits, say N bytes starting at the beginning of the session? This allows working on application-layer approaches to MITM detection. If there's no such access, perhaps there should be. With that in place, it's possible to try out web server/browser-level approaches. The Mozilla crowd has been struggling in this area for a while now to untangle the fake cert mess. This could help. Anybody working on this? John Nagle ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
