Alternatives to OpenSSL
If the recent flaws that have been detected in OpenSSL have left you feeling a little bruised then perhaps you're open to considering some alternatives. However, it's important to note that while a shift away from OpenSSL may be warranted in your organisation, it doesn't abrogate your need to test and verify.
As the Heartbleed and CCS Injection Vulnerability flaws were not in the TLS and SSL protocols but in how OpenSSL implemented them, it's possible to consider alternatives for using these protocols. One is GnuTLS. It's also open-source, like OpenSSL, but implements the SSL and TLS protocols differently. There's an API for applications to hook into so it could be a viable alternative, albeit one that will require significant software engineering to implement in some cases, for companies considering a shift away from OpenSSL.
Another is Network Security Services (NSS) that is released under the Mozilla Public License. A number of popular open source and commercial applications use NSS such as Chrome, Open Office, Apache and Java.
Then there's the Microsoft stack of server and communications products. These provide another alternative as they use Microsoft's own implementation of the TLS and SSL protocols. One advantage of this solution is that Microsoft has an established process for releasing fixes and patches on Patch Tuesday each month. However, this might require a platform shift that could be prohibitively expensive and complex.
The Final Word
Heartbleed was an important milestone in information security. Although it caused massive disruption as companies scrambled to patch vulnerable systems and forced users to change passwords it can be viewed as opportunity to take stock and learn.
The reality is that many of the building blocks of our systems that rely on need to be reconsidered. OpenSSL was used by millions of people for many years. It will remain a significant part of many organisations' systems or many years. But we can no longer expect that it will be secure.
Any open source code that is being used in companies needs to be reviewed with a hacker's point of view, looking for potential security issues rather than whether the software satisfies functional requirements.
The entire development and testing process needs to be overhauled so that security is in the foundation and not an afterthought.
And, if necessary, it might be time for businesses to remove OpenSSL from their environments and deploy an alternative, while maintaining a "trust, but verify" posture.
This article is brought to you by Enex TestLab, content directors for CSO Australia.
Featured Event: ISACA Strategic Planning Event | 1st July | Sydney Rooms- darling Park | Register Today