10
$\begingroup$

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?

| cite | improve this question | |
$\endgroup$
10
$\begingroup$

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

| cite | improve this answer | |
$\endgroup$
  • $\begingroup$ So we are basically communicating the certificates through a second channel, we know to be secure? $\endgroup$ – TVSuchty Feb 23 '19 at 11:44
  • $\begingroup$ Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates). $\endgroup$ – dkaeae Feb 23 '19 at 11:45
  • $\begingroup$ But why would not we talk about the channel, we know to be secure, in the first place? $\endgroup$ – TVSuchty Feb 23 '19 at 11:47
  • 1
    $\begingroup$ @TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted. $\endgroup$ – chi Feb 23 '19 at 11:51
  • 1
    $\begingroup$ @TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys. $\endgroup$ – chi Feb 23 '19 at 12:33
5
$\begingroup$

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.

| cite | improve this answer | |
$\endgroup$
  • $\begingroup$ Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate? $\endgroup$ – TVSuchty Feb 23 '19 at 11:35
  • $\begingroup$ I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key. $\endgroup$ – David Richerby Feb 23 '19 at 11:39
  • $\begingroup$ @TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes. $\endgroup$ – Willtech Feb 24 '19 at 0:33
  • 1
    $\begingroup$ @TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate. $\endgroup$ – gnasher729 Feb 24 '19 at 14:51
  • $\begingroup$ Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”. $\endgroup$ – gnasher729 Feb 24 '19 at 20:06

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.