The question pretty much sums it up.

Is there any way to make an attacker who is successfully performing an MITM attack to actually not be able to read or change the messages? Assuming there is no pre-attack key transfer or an agreed upon key that isn't transferred mid-attacking conversation.

  • $\begingroup$ Yes there is indeed. $\endgroup$ – SEJPM Aug 30 '15 at 20:45
  • $\begingroup$ Could you explain how? $\endgroup$ – Addison Crump Aug 30 '15 at 20:57
  • 2
    $\begingroup$ You might be interested in quantum key distribution, where it is possible to detect the presence of an eavesdropper by the quantum effects their measurement of your communication causes. $\endgroup$ – Matthew Towers Aug 31 '15 at 10:39
  • 4
    $\begingroup$ If you have users with no trust relation to anyone else, there is no way they could distinguish anyone else. In any scenario Eve could say "Hello I am Bob", and if Alice doesn't trust anyone and doesn't know Bob, there is no way she could verify that claim. $\endgroup$ – tylo Aug 31 '15 at 11:27
  • 1
    $\begingroup$ @VTCAKAVSMoACE No, a trust system needs to be in place. But a MITM can still succeed if the protocol and algorithms are chosen poorly. $\endgroup$ – Maarten Bodewes Aug 31 '15 at 17:53

You can't get a man-in-the-middle (MitM) resistant channel out of a vacuum.

You need some common knowledge beforehand. Luckily all one needs is a shared trust relation.

Suppose the server Steve trusts Carol, suppose further the client Charlie trusts Carol aswell.

As an example I'll give a simplified TLS-RSA key exchange because it's particularly easy.

First Steve needs to submit his public RSA key to Carol for certification. Carol digitally signs Steve's key and embeds in an certificate tying his name ("Steve") to his public key. It is assumed that Charlie can verify Carol's signature. This only needs to be done once.

Charlie now initiates a connection to Steve containing the request for communication and specifying the available cipher suites Charlie supports. They contain informations on how to encrypt and authenticate the data after the key-exchange is finished. Further a random number will be sent in the initial message. Steve will answer with his selection of the cipher suite and his random number.

In the next step Steve will send his certificate. Charlie will verify the certificate by checking Carol's signature and if it's valid will accept the key to be from Steve. Now Charlie randomly chooses a random "pre-master secret" and encrypts it using Steve's public key. He sends this to Steve. Charlie now derives the master secret from his random number, the pre-master secret and Steve's random number. Now Charlie sends a message indicating that from now on the selected encryption methods shall be used. He finishes this messages with a message authentication code (MAC) on all previous data using the master secret as key.

Only Steve will be able to decrypt this pre-master secret. He decrypts it and derives the master secret himself. Now he verifies the MAC he received. Next he sends the message indicating he's ready to use encryption. He finishes with the same MAC (on all previous data).

Charlie verifies it and can be assured that no MitM attack has taken place because only the holder of the private key could have sent the MAC and he knows that Steve is the holder of the key because Carol confirmed it via the certificate.

Now a standard pre-shared key data exchange protocol starts (a.k.a. "record layer" in TLS terms)

TL;DR: You use digital signatures to bind public keys to identities and use those keys to construct secure key-exchanges.

  • $\begingroup$ This isn't quite what I asked. I understand how the RSA key exchange works, but I was asking about before any key exchange occurs. If there was a detail in my question that I forgot to mention that I mentioned in the comments, I apologize, but this isn't what I meant. I was asking about a person-to-person, immediate intercept attack before they have exchanged keys. $\endgroup$ – Addison Crump Aug 31 '15 at 13:23
  • $\begingroup$ @VTCAKAVSMoACE, for this key exchange they don't need to exchange anything with each other beforehand. Steve needs to interact with Carol at some point and Charlie needs to interact with Carol to obtain her public key. If you don't allow any third parties, there's no way to secure this without prior interaction. $\endgroup$ – SEJPM Aug 31 '15 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.