DoS attack against Diffie-Hellman protocol
dheat-attack.com
DoS attack against Diffie-Hellman protocol
1–9 of 9 posts
Re: DoS attack against Diffie-Hellman protocol
#2Who is affected?
Websites, mail servers, and other Transport Layer Security (TLS) dependent services that support Diffie-Hellman key exchange using ephemeral keys (DHE cipher suites) are at risk of the DHEat attack. Services using other cryptographic protocols can also be affected.
* Secure Shell (SSH) services support Diffie-Hellman key exchange methods. * Internet Protocol Security (IPsec) services offer DH groups. * OpenVPN servers support Diffie-Hellman key exchange in the control channel (DHE TLS ciphers).
Re: DoS attack against Diffie-Hellman protocol
#3DHE has already been considered weak, with ECDHE as the recommended replacement, for a long time now, so I suspect that most systems operated by people who take security seriously already won't be vulnerable to this.
Re: DoS attack against Diffie-Hellman protocol
#4I’m getting a certificate error.
Re: DoS attack against Diffie-Hellman protocol
#5I’m getting a certificate error.
Qualys is too [1]
[1] - https://www.ssllabs.com/ssltest/analyze.html?d=dheat-attack....
Re: DoS attack against Diffie-Hellman protocol
#6DHE has already been considered weak, with ECDHE as the recommended replacement, for a long time now, so I suspect that most systems operated by people who take security seriously already won't be vulnerable to this.
Your post corroborates SUSE[0] claims that ECDHE is not vulnerable to this. Default golang TLS server looks like it's got it's head on straight for this.
Re: DoS attack against Diffie-Hellman protocol
#7I’m getting a certificate error.
Looks like the URL for this post should be this instead: https://dheatattack.com/
Re: DoS attack against Diffie-Hellman protocol
#8This is one year old (11/11/21), see date at the bottom:
Re: DoS attack against Diffie-Hellman protocol
#9I'm a bit confused what the attack is. Is it just that SSL handshakes are expensive for the server, while the client avoids the computational cost because it chooses a random public key instead of one for which it knows the private key?
And why doesn't this also apply to plain RSA and ECDHE_RSA suites, which need to compute an expensive RSA private key operation, which should be similarly expensive as DH?