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

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
by patents. However, his explanation is almost incomprehensible.
There's a thesis that explains it, though.

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                       
Development Mailing List             
Automated List Manager                 

Reply via email to