Securely implement and configure SSL to ward off SSL vulnerabilities

Secure Sockets Layer (SSL) has been under constant attack since it was developed by Netscape in 1994. The security and integrity of the X.509 Public Key Infrastructure has encountered more questions recently, but improvements have been made in response to the attacks and research. My SearchSecurity.com tip on SSL from September, 2010 discussed many of these SSL vulnerabilities at that time, but additional improvements have been made in the last two years.

Despite the warnings about SSL security, if implemented and configured correctly, SSL can still be used to secure the transport of data across unsecured networks. In this tip, we’ll examine the extent to which SSL vulnerabilities represent a threat to enterprises today and offer ways to implement and configure SSL securely.

SSL security questions

Due to the increased reliance on SSL for protecting communications, insecure usage of SSL presents more of a threat to enterprises and users now than it did two years ago. Recent attacks include the issuing of man-in-the middle certificates by Comodo, DigiNotar and other attacks where PKI certificate authorities (CAs) have issued fraudulent intermediate CAs or server certificates that could be used to attack SSL connections. These certificates could even be used by organizations to monitor the communications on their own network.

But the bigger threat is in the perceived protections that don’t exist. SSL does not provide everything a Web application or system needs to secure the data or the system. SSL does provide strong protections for data transported across networks and cryptography can protect data in many other places. If the SSL or cryptography implementation is insecure or the system is insecure, the strength of the algorithms protecting the system does not matter.

Beyond the questions about SSL’s core cryptography and key-exchange methods, more serious flaws are often found in enterprise SSL implementations. These flaws include enabling weak encryption and using a certificate for a different hostname.

Defending against SSL vulnerabilities

If and when there are vulnerabilities found in SSL, organizations should keep up to date on patches so most of the fixes can be implemented in a similar fashion as any other software is patched or secured. Given the complexity of SSL and the various devices supporting it, this could be a daunting task that requires significant effort if the patches or changes are not backward-compatible. Just like for any other patch, the patches for SSL Certifiate should be tested thoroughly to ensure it doesn’t break any functionality. The test systems might also need to be connected to the patched systems to ensure they are still able to connect.

To guard against SSL vulnerabilities, enterprises should first ensure the basics from my 2010 tip have been covered, but there are additional steps that can be taken. These protection efforts by enterprises can be broken down into three areas: users, customers and services. Enterprises can protect their users by installing browser plug-ins that force SSL usage if it is supported by the remote host. Tools for this purpose include the Electronic Frontier Foundation’s FireFox plug-in, called HTTPS Everywhere, which forces the use of SSL when available, and Convergence, which allows greater control over which CAs are trusted by the browser. Enterprise users should also receive some security awareness training to ensure they use secure connections. Users should not need to make sophisticated and technically detailed decisions about how to secure their communications, but they should understand the necessity of using secure connections. These same protections can be suggested to an organization’s customers, but the organization can only provide services over secured connections to help reinforce good habits.

Enterprises should also ensure any older, less secure SSL implementations are retired or disabled to protect services against downgrade attacks where client systems are tricked into using unsecure connection methods. The Internet Engineering Task Force has been working on improvements to SSL to get the SSL ecosystem to improve the state of security. Recommendations from the Trustworthy Internet Movement’s SSLPulse on how to securely deploy SSL are also worthy of review.

Conclusion

The SSL protocol can still be implemented and used securely, but the risks and vulnerabilities of unsecure SSL usage are now more widely known outside of SSL experts. SSL is still only one part of the overall Web security challenge. The core cryptography and key-exchange methods will always be the focus of active research to find new attacks and identify improvements, but the implementation details could yield the most improvements in security. End users will likely never notice many of these improvements, but they will need to be implemented by organizations, server operators and software developers. The importance of SSL has only increased in the last two years. More users utilize varied networks or devices to access social networks and the Internet, but they still want their Internet usage protected by an encrypted connection.