0

Diffie-Hellman and MIM attack:
When variants of Diffie-Hellman algorithms like DHE, ECDHE etc. are used in SSL handshake for key exchange then can it become prone to man in middle (MIM) attack.

Suppose, SSL handshake has started and now it is time of key exchange, so client computes its public key part of DH and sends it, now bad guy sitting in the middle intercepts it and computes its public key part of DH and sends it. And then both computes the shared secret from each other's public key and shared secret is established. Now even though the traffic is encrypted using the shared secret but since the bad guy did all this, so he will be able to decrypt it. No?

In case of RSA, since anything encrypted using public key can only be decrypted using private key so it is safe. I am sure about this, but with DH I am getting above doubt.

Server identity:
Suppose cipher is TLS_ECDHE_RSA..... Now, as I understand ECDHE is for key exchange and RSA is to prove server identity or authentication. But how RSA is used to prove the server identity or authentication because it is done with digital signature, right? Client will see the server's DC is signed by a trusted CA and he will identify and trust the server. Then how "_RSA" or "ECDSA" part of cipher suite comes into picture to prove server's identity or for authentication?

I have read a lot of algorithm explanation for key exchange thing but never about server's identity or for authentication from "_RSA" or "ECDSA" part of cipher suite.

hagrawal
  • 205
  • 2
  • 11

2 Answers2

2

Diffie-Hellman and MIM attack: When variants of Diffie-Hellman algorithms like DHE, ECDHE etc. are used in SSL handshake for key exchange then can it become prone to man in middle (MIM) attack.

Suppose, SSL handshake has started and now it is time of key exchange, so client computes its public key part of DH and sends it, now bad guy sitting in the middle intercepts it and computes its public key part of DH and sends it. And then both computes the shared secret from each other's public key and shared secret is established. Now even though the traffic is encrypted using the shared secret but since the bad guy did all this, so he will be able to decrypt it. No?

In case of RSA, since anything encrypted using public key can only be decrypted using private key so it is safe. I am sure about this, but with DH I am getting above doubt.

It seems you are describing something like the scenario below (source):

DHE MITM

Notice that the man in the middle replaces the certificate and public key for the legitimate domain with their own cert and public key before DH parameters are exchanged. The MITM then uses their public key to sign the DH parameters. Now what should happen is that as soon as the client receives the cert it should check that the cert is issued for the domain it thinks it is connecting to (Server S). When it is presented with a cert for a different domain from the MITM (Server A) it should reject that cert and not proceed with key exchange. In a more concrete example, consider a client wants to connect to https://www.google.com and instead of getting a cert for the domain google.com it gets a cert for the domain evil.com (signed by a trusted CA). Obviously the client should not interpret this cert as being valid.

Server identity: Suppose cipher is TLS_ECDHE_RSA..... Now, as I understand ECDHE is for key exchange and RSA is to prove server identity or authentication. But how RSA is used to prove the server identity or authentication because it is done with digital signature, right? Client will see the server's DC is signed by a trusted CA and he will identify and trust the server. Then how "_RSA" or "ECDCA" part of cipher suite comes into picture to prove server's identity or for authentication?

I have read a lot of algorithm explanation for key exchange thing but never about server's identity or for authentication from "_RSA" or "ECDCA" part of cipher suite.

Yes, the cert that the MITM presents may well be valid and signed by a trusted CA, but the MITM cannot get a certificate for Server S.

Note that there have been cases where the domain in the cert is not checked against the domain being connected to (such was the case in the Chase mobile app for a while!), you can read about such cases in this paper, but this is an implementation issue, properly implemented TLS does not allow this scenario.

puzzlepalace
  • 681
  • 3
  • 11
  • In the first question, I asked only about MIM in case of key exchange, certificate is already validated but when it is time of key exchange then MIM will come in picture and do key exchange. In the second question, I wanted to know about authentication. – hagrawal Aug 20 '15 at 12:43
  • Regarding the first question, if the certificate is already correctly validated then the MITM cannot change any DH data the server sends. That data is signed via the private key (RSA in most cases) of the server and validated by the client via the public (RSA) key contained in the certificate. If the MITM changes the DH params and signs with their own key then the client will fail to validate the signature. – puzzlepalace Aug 20 '15 at 13:00
  • Thank you for your inputs. You said - "*That data is signed via the private key (RSA in most cases) of the server and validated by the client via the public (RSA) key contained in the certificate.*". It DH parameter is signed via private key of server then how it can be verified using public key. I am really not sure about this, what I know for sure is a data encrypted by public key can be decrypted by private key but not other way round. – hagrawal Aug 21 '15 at 18:41
  • 1
    You should look at [this answer](http://stackoverflow.com/a/454069/4179728) which should help clarify. – puzzlepalace Aug 21 '15 at 18:47
  • Thank you, it was useful. So, you mean authentication is done by verifying something using the server's public key which is present in DS. Two questions - (1.) As per Thomas Pornin's answer here: http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work, there is no such thing sent in ServerHello which client would verify. (2.) How it would happen in case of ECDSA because as per my knowledge DH based cipher generates new public-private key each time. *P.S. Please don't mind the questions, I have less information on cryptography.* – hagrawal Aug 22 '15 at 16:34
1

But how RSA is used to prove the server identity or authentication because it is done with digital signature, right?

Yes. The key exchange parameters are signed with the server's long term key. (Such a key used to be mostly RSA, but ECDSA is becoming quite common now.)

Further reading

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • Thank you, I have read the link you have provided but it doesn't explain how RSA is used to prove the server identity or authentication? It says same thing that it verifies the certificate chain and confirms that legitimate server has responded. But it doesn't explain how RSA is used for authentication, and how authentication will happen in case certificate is ECDSA based. – hagrawal Aug 21 '15 at 18:38