Post-Heartbleed: Is it time to kill OpenSSL?
Time to bottle open source?
The Heartbleed Bug (and it's definitely a bug - not a virus) has ignited a debate around the security and reliability of open source software in recent months.
Discovered by researchers at Google and Codenomicon, the vulnerability was found in the open source OpenSSL cryptographic software library that provides Secure Sockets Layer (SSL) and Transport Layer Security (TSL) protection for anything from emails and web browsing to internet banking.
The programming mistake that led to Heartbleed - which was accidentally introduced by German programmer Dr. Robin Seggelmann, a frequent contributor of OpenSSL code - allows attackers to download 64k chunks of data stored in the supposedly secure main memory of servers.
It was an honest mistake, but one with far-reaching consequences. According to Errata Security, around 320,000 of 600,000 detected vulnerable servers are still vulnerable to Heartbleed.
Post-Heartbleed, every private key on servers running OpenSSL is now suspect and could be potentially used by attackers to impersonate secure websites so long as those servers remain unpatched.
Is it time to switch from OpenSSL to a commercial solution (or another alternative) when it comes to web security? We spoke to industry experts at Infosec 2014 to find out more.
Keep open source - it still has lots to offer...
James Sherlow, SE Manager WEUR at Palo Alto Networks, thinks that ditching OpenSSL in the wake of Heartbleed would be something of a knee-jerk reaction:
Are you a pro? Subscribe to our newsletter
Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed!
"OpenSSL is still highly relevant and has scalability. It has a community of highly skilled developers, which is extremely valuable and still valid. Every software at a certain point in time will have some sort of vulnerability associated with it, but it doesn't mean we switch it off; it means we learn from our lessons."
…but Heartbleed was a wake up call
"I think that the open source community needs to start putting mechanisms in different areas that could cross-check others. That's better than finger pointing and blame which doesn't get anyone anywhere. It would mitigate the risk, reduce the chance of attack and raise the bar. To get to zero errors is difficult, but let's aim for it. That's the bar."
You couldn't just scrap it anyway...
The question of whether we should get rid of OpenSSL isn't so black-and-white, according to JD Sherry, VP of Technology & Solutions for Trend Micro. He believes that instead of turning down the services of dedicated and talented open source contributors, rewards should be offered to others who seek out errors in their work:
"Open source is always going to be an innate part of what we do, primarily because there's lots of great engineering involved with it - a lot of people pour their passion into these projects and a lot of excellent work comes out of them."
…so let's introduce more Bug Bounties
"Companies like Google, Microsoft and Facebook have got together to dump $100,000 each to get to the heart of Heartbleed, which isn't enough to stop a potentially similar scenario. Bug bounties, on the other hand, are supposed to self-regulate on the bug issue, and they can be extremely important.
"The cost of implementing and paying out for them can be well worth the outcome that comes with a major flaw in your software that was missed during the quality control process. Whether open source or not, they're going to be critical in making sure we don't have a tremendous amount of Heartbleed or other OpenSSL cases."
OpenSSL was broken from the start...
Not everybody has been so forgiving when it comes to OpenSSL. FreeBSD and security developer Poul-Henning Kamp called for its head in a blog post titled Open SSL must die, for it will never get any better:
"And that brings me back to OpenSSL — which sucks. The code is a mess, the documentation is misleading, and the defaults are deceptive. Plus it is 300,000 lines of code that suffer from just about every software engineering ailment you can imagine."