Is SSL Secure enough? (Part 2 of 3)
by Posted on 08.05.2010 04:45 PM
Apologies on the delay folks. It was an exciting week at Blackhat that kept me from posting part 2 of 3. Without further stalling- the second installment:
Transport Layer Security Research Gone Wild
SSL has been the object of security researchers for the last year.
The researchers have developed techniques for decrypting SSL data, attacking SSL enabled web applications & masquerading as “authenticated” systems. This was possible due to flaws in the implementation of SSL & x.509 certificates. Developers should be aware that simply using a security technology is insufficient for establishing security- it must be properly implemented.
Here are some stories about successful attacks against SSL that anyone using SSL should be aware of:
SSL renegotiation bug used to successfully attack twitter: http://www.darknet.org.uk/2009/11/ssl-renegotiation-bug-succesfully-used-to-attack-twitter/
Windows CryptoAPI x.509 Null Character Exploit:
Blackberry Device Certificate Spoofing:
Moxie Marlinspike- Defeating SSL
OpenSSL vulnerability in SSL2 handshake process
MD5 SSL summary
Defeating https via cache injection
Internet SSL Survey 2010
After reading these links, you may be losing hope. Please, do not loose hope. Keep reading. I’m trying to use a dramatic structure I read about called a “story-arc.” Hopefully you are experiencing excitement and tension which I will relieve by describing several techniques for avoiding this catastrophe. You should start feeling less hungover now too.
One of the more important long poles in security is implementation. The previously discovered vulnerabilities & hacks were basically software bugs. Thankfully, changes have been implemented to remove many of these vulnerabilities. The onus is on the developer to ensure that the fixes get carried into new solutions. Here are some gotchas you should be aware of as you’re implementing SSL:
- Failure to validate the certificate
- Wrong SSL version
- Improperly implemented SSL stack
- Improperly signed certificate
You need to enforce the Certificate Validation process. You probably want to use only a specific certificate- not just any certificate that was issued from a particular root CA.
Wrong SSL version
OpenSSL has a vulnerability in it’s implementation of SSL 2.0 that can enable arbitrary code execution. Many systems that impelment SSL stacks have based them off of OpenSSL’s implementation. Consequently, there are many systems that have reproduced the exact same weakness. If you have a mobile client that connects to a web server using SSLv2, you are at risk of having an attack against your server infrastructure. Make sure you’re using the most up-to-date implementation of SSL.
Improperly implemented SSL stack
The previously mentioned x.509 null character exploit was due to a poor implementation of SSL. Attackers who are able to get in the route of the SSL session could terminate the end to end encryption of an SSL session by purchasing certificates with a null character in the certificate name. If your solution is not using the most up-to-date implementation of SSL, it may be possible to view the break the end to end encryption & implement a “Man in the Middle Attack.”
Improperly signed certificate
Self signed certificates are useful when debugging. When it’s time to go to production, you’ll want to ensure that the trust chain is implemented correctly by using a certificate from a trusted Certificate Authority (CA). Another challenge is in the signing algorithms used in certificates. MD5 used to be the signing algorithm of choice. MD5 has been discovered to be vulnerable to collisions which could result in 2 distinctly different certificates producing the same hash. In a secure signing algorithm, this should be impossible. SHA-1 does not have the same level of problems as MD5 does. You should confirm that your certificates are using the most secure algorithm accepted in the marketplace. As of the time of this writing, SHA-1 is the preferred signing algorithm.
Next week, we’ll wrap up the SSL story by talking about things to keep in mind when writing SSL-enabled applications.
Patrick McCanna is a Lead Member of Technical Staff in the Chief Security Office at AT&T. He advocates security in AT&T mobility Device, Service & Network offerings. He has a B.S. in Computer Science with a Math minor from Linfield College. He has worked in the security industry for 12 years and the mobility industry for 6 years. Patrick has delivered presentations on mobile security on Capital Hill & at RSA, Bluehat and VON.