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

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.

For concreteness, suppose the server does the SSL/TLS handshake, then sends the HTTP headers, which contain the cryptographic hash of the material to follow. This is done as fast as possible. The server then sends most of the rest of the document. But at the end of the document, it pauses until 3 seconds have elapsed from receipt of the HTTP request before sending the last hundred bytes or so. Most of the document will still render, although "onload" Javascript won't trigger yet.

At the receiving end, the browser only allows the server 2 seconds from HTTP request to headers received. If the server can't keep up, the page will be treated as untrusted.

This provides considerable MITM protection. An attacker must be able to fake page content to defeat this.