10

I have heard about all these Man-In-The-Middle Attack preventions and I am wondering, how this can possibly work if the man in the middle only listens to your stream and does not want to change the message itself.

Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?

How can a certificate prevent this?

Edit:

I have heard that the certificate authority generally says: "Yeah, that is the other ones key". But how can I be certain, that the signature of the certificate is not fudged?

Discrete lizard
  • 8,392
  • 3
  • 25
  • 53
TVSuchty
  • 287
  • 1
  • 10

2 Answers2

10

Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?

Yes, they can.

A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-middle (MITM) attacks, as you have stated.

Certificates are an attempt remedy this, but another problem arises: How can you ensure both parties receive the correct certificate? Obviously you cannot just send the certificates over the insecure channel since this is again susceptible to a MITM attack.

The solution is the existence of an alternative, (completely) secure channel. This would be either the two parties meeting in person and exchanging their certificates physically or over some alternative, trusted channel (e.g., over telephone, if it can be trusted).

In computer networks, the alternative channel is usually a public-key infrastructure (PKI). This means your operating system or browser has a set of preconfigured root certificates from which other certificates are signed (and possibly even further certificates using these as intermediate certificates). Hence, when you visit some website, it presents a signed certificate, which is signed using (a chain of) certificates which you already trust. Then, by using this certificate, an authenticated key exchange is possible (e.g., to agree on an ephemeral key to use with ordinary symmetric encryption).

dkaeae
  • 5,057
  • 1
  • 17
  • 31
5

In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process.

The problem is that you don't know whether or not you really have Bob's key. Certificates get around this because the certification authority (CA) gives Bob a digitally signed message saying "Bob's key is 12345". You can verify this certificate because there aren't many CAs so your browser just contains a list of valid CA keys. Now, if Eve intercepts your attempt to start encrypted communication with Bob, she has two choices. If she tells you that Bob's key is 67890, then either she doesn't provide a certificate and you say "Sorry, you need to prove that" or she provides a fake certificate and you say "That certificate isn't valid." Alternatively, she tells you that Bob's key is 12345 and provides a valid certificate of that, but this is no use to her because she doesn't know Bob's private key, so she can't decrypt the messages she's relaying between the two of you.

David Richerby
  • 82,470
  • 26
  • 145
  • 239