Security researchers from Google have recently proposed (http://bit.ly/oK3hbp) a fix to improve the security of the Secure Sockets Layer (SSL) encryption protocol that websites use to protect communications against eavesdropping and counterfeiting. Below is a comment from Amichai Shulman, CTO and co-founder of Imperva:
"Google has added server side support for a new strand of the Diffie-Hellman (DH) key exchange protocol. Their assumption is that in ten years from now someone might break the RSA key exchange protocol (or at least make it practical to break certain key sizes) and would use that capability to go back and decipher recorded streams. But here is where they got it wrong:
1. Using larger key sizes today would have made this concern irrelevant (at least for 50 years)
2. Presumably in 10 years someone might be able to break DH more efficiently (although DH has a stronger theoretical basis than RSA), or even AES.
Yet, a greater problem remains. In the past couple of years, we have witnessed the attacker community focusing on some practical types of attacks which Google's enhancement does not address at all:
- Attacks against PKI. Over the past year, attackers have repeatedly compromised various CA organizations. These include, DigiNotar, GlobalSign, StartSS, Comodo and Digicert Malaysia. A hacker, who gains control on any CA, can then use it to issue fraudulent certificates and masquerade any website.
- The theft of issued certificates. While SSL prevents access to traffic by attackers it has no built-in mechanisms that allow restrictive access to it by collaborative 3rd parties. For example, proxies, load balancers, content delivery networks (CDNs) need to access the certificate's private key in order to access application data. As a result, the digital certificate is now stored in many locations - some residing outside of the site's physical environment and out of the application's owner control. These open up additional attack points which imply a higher success rate for attackers.
- Denial of Service attacks. The heavy computational burden incurred by the SSL-handshake process leaves SSL-protected resources prime candidates for effective Denial of Service (DoS) attacks. Together with an increased consumption of computer resources per session, a multitude of simple attacks can be devised very efficiently."
"Google has added server side support for a new strand of the Diffie-Hellman (DH) key exchange protocol. Their assumption is that in ten years from now someone might break the RSA key exchange protocol (or at least make it practical to break certain key sizes) and would use that capability to go back and decipher recorded streams. But here is where they got it wrong:
1. Using larger key sizes today would have made this concern irrelevant (at least for 50 years)
2. Presumably in 10 years someone might be able to break DH more efficiently (although DH has a stronger theoretical basis than RSA), or even AES.
Yet, a greater problem remains. In the past couple of years, we have witnessed the attacker community focusing on some practical types of attacks which Google's enhancement does not address at all:
- Attacks against PKI. Over the past year, attackers have repeatedly compromised various CA organizations. These include, DigiNotar, GlobalSign, StartSS, Comodo and Digicert Malaysia. A hacker, who gains control on any CA, can then use it to issue fraudulent certificates and masquerade any website.
- The theft of issued certificates. While SSL prevents access to traffic by attackers it has no built-in mechanisms that allow restrictive access to it by collaborative 3rd parties. For example, proxies, load balancers, content delivery networks (CDNs) need to access the certificate's private key in order to access application data. As a result, the digital certificate is now stored in many locations - some residing outside of the site's physical environment and out of the application's owner control. These open up additional attack points which imply a higher success rate for attackers.
- Denial of Service attacks. The heavy computational burden incurred by the SSL-handshake process leaves SSL-protected resources prime candidates for effective Denial of Service (DoS) attacks. Together with an increased consumption of computer resources per session, a multitude of simple attacks can be devised very efficiently."
