John, To detect MITM in a browser context, some people are running Flash programs or applets to open raw TCP connections to retrieve certificates seen on the wire. Then they compare them with what they are supposed to be seeing. There's some information about this approach in this presentation (slide 73):
http://www.slideshare.net/mimeframe/ruxcon-2012-15195589 Of course, the MITM can strip out such code, but they first need to know the code is there. This approach is easy to implement because you can inject a HTML snippet into the application, e.g., from a web application firewall. I developed this method for ModSecurity (an open source web application firewall) some years ago, in order to inject JavaScript code into applications to perform integrity checks and XSS detection from within browsers. Just wanted to share what others are doing in this area. On Tue, Feb 26, 2013 at 8:40 PM, John Nagle <[email protected]> wrote: > 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 [email protected] > Automated List Manager [email protected] -- Ivan Ristić ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
