3

I am going through CISSP materials and I got stuck on Secure Exchange Protocols such as Diffie Hellman and RSA. It is known that DH by itself is vulnerable to MiTM. So the answer is to use authentication methods such as certificates. That's fair and square because that's what https is based on. But how does that make it MiTM proof if we have things like SSL inspection? SSL inspect is by nature a MiTM attack designed to intercept encrypted traffic by injecting its own certificate and looking like the CA for the destination's certificate. Most modern AV solutions today do the same thing. If you check certificates of the https websites you go to, they will be signed by your AV vendor.

These are the sources I have used

https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/what-is-diffie-hellman.htm

How do RSA fingerprints protect from MITM attacks?

https://stackoverflow.com/questions/10471009/how-does-the-man-in-the-middle-attack-work-in-diffie-hellman

The RSA article says "Even though Carol is still able to intercept messages between Alice and Bob, she cannot forge signatures without Alice's private key and Bob's private key."

My question is, why would she need to do that? If she is intercepting their data, she can simply use a certificate signed by her and pretend to be either party. She can use her own private key for signing and decryption because she already provided both parties with her own public key. Then re-encrypt the data with the destination's public key and pass it on. Isn't that exactly how SSL intercept works?

The only way around this I can think of is that her CA used to sign the fake certificate would not be in the trusted certificate root stores of the victims. But when I think back to all the L2L VPNs I have created using Diffie Hellman, neither of those things (certificates or cert root stores) were used.

I must be missing something here.

2

The reason is the one you highlight at the bottom. You are trusting the certificate. Certificates used for performing MiTM on a corporate level, such as when doing SSL inspection, relies on having an internal CA deployed that is trusted by the computers in the domain. Often the trusted CA is pushed down by the domain controller on the domain machines.

L2L VPNs use IPSec which implements DH for key exchange (IKE):

  • Phase I: The peers authenticate, either by certificates or via a pre-shared secret. Authentication.
  • Phase II: A Diffie-Hellman key is created. The nature of the Diffie-Hellman protocol means that both sides can independently create the shared secret, a key which is known only to the peers. Key exchange.

Have a look here for a more in-depth discussion

  • Hi Lucas, thanks for the reply. The pre-shared key did spring to my mind after I posted the question so thank you for confirming that. I checked the phase 1 config and authentication is indeed listed there as part of the ISAKMP tunnel negotiation. Thanks again. – Martin S Mar 30 '17 at 9:34

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.