How to stay protected for Heartbleed and other OpenSSL flaws

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

CSO Perspectives Roadshow 2014 | Melbourne 2nd September | Canberra 9th September | Sydney 18th September | Over 33 Speakers , International Speakers, Workshops, & Giveaways Register today


Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Follow our new CSO Australia LinkedIn
Follow our new social and we'll keep you in the loop for exclusive events and all things security!
CSO WANTED
Have an opinion on security? Want to have your articles published on CSO? Please contact CSO Content Manager for our guidelines.

Tags hackersSSLzimbraTLSsuse linuxredhatOpenSSLHeartbleedexploitedCCS Injection vulnerabilityNSS (Network Security Services)CVE-2014-0160Common vulnerabilities

More about ApacheAppleAustralian Pharmaceutical IndustriesCCSCSOEnex TestLabISACALinuxMicrosoftMozillaRed HatSymantecTrend Micro AustraliaZimbra

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Brand Page

Stories by Anthony Caruana

Latest Videos

More videos

Blog Posts