Posted by Synopsys Editorial Team on April 8, 2014
Serious question: is it better to rewrite a library that’s had a lot of implementation problems, or is it better to keep hardening OpenSSL?
— Michael Nygard (@mtnygard) April 7, 2014
Is OpenSSL really not salvageable? Should we write a new version from scratch? While flattering, I think that Gary’s comment deserves to be evaluated.
— Gary McGraw (@cigitalgem) April 7, 2014
Let’s talk about what it would take to start from scratch with a library like OpenSSL.
There’s huge list of people that need to be involved when considering a project like this. We will quickly see that it takes a village. Let’s examine the most important:
Say what you want about this tactic, there has to be someone that leads an effort like this. They have to call the shots, and they have to be chosen wisely. Building a library like this will bring with it a lot of opinions on how to build and organize things. Someone has to be able to see the forest for the trees and help people understand the big picture.
The task of distributing such a widely used library across every OS/distro combination is huge. We need the support of these folks to make it actually happen. Without proper packaging a library will never see the adoption it is looking for. With the growing number of package systems and OS distributions, this can be a challenging task.
Cross OS compatibility is hard, and we will need people who understand the intricacies of all the major OSes and CPU architectures. With the likely implementation language still C this knowledge will be essential. With ARM and other alternative architectures becoming more and more popular, proper knowledge will be required. There are also many embedded devices that use OpenSSL.
Someone has to actually write code. OpenSSL is a reasonably sized library. While a rewrite will likely only contain a fraction of the volume of code, there’s still a lot of work to do. The initial team of people that do the implementation will need to be skilled developers that really understand the language of choice. Since this is likely to be C, this ups the stakes quite a bit.
A team of people needs to be dedicated to trying to break the library. They need to understand how to properly test a library like this and in what ways the library can be used.
A team of reviewers needs to ensure that the overall design of the library is free from flaws and that the code being written is free from vulnerabilities. Like the builders, they need to master the implementation language. On top of this they need to develop a good static analysis workflow and help the builders understand when potentially dangerous choices are made.
We need a few folks who actually understand crypto and can review the implementations. This is absolutely essential to the success of the project. There will be a lot of questions around involvement from private companies and motives for being involved at this level, but at the end of the day it will be the support of the people leading the crypto community that make the biggest impact.
With a library like this, there will be lots of support and integration requests. In order to ensure success of the library, it has to remain visibly active and support its users. This means tending to issues, working with integrators, maintaining a blog, moderating a mailing list, and all the other community focused things that are involved with running a library as big as this.
Once the library is ready for consumption, it has to be put to use. This means integration with all of the major applications that use it. This is by far the biggest obstacle, and will likely take the most amount of time. The web servers will likely be the first to take on this task, but not far behind will be the programming languages and other higher level libraries that use OpenSSL. No real progress will be made until the integrations are complete and their software is using this new library.
To do this properly will cost a lot of money and time. If we are considering the effort, we should do it justice by trying to scope the work and get the expected costs associated. After that, we should at least double it. The reality is that it will be an even higher number than expected. Lots of companies and universities will need to volunteer time or money to make this happen. If we were to start anywhere, I beg the community to start here and understand what the real effort looks like.
It’s plain and simple. Even if we were to gather the required people, find the funding to get things built properly, and start tomorrow, we’re still looking at several years before this becomes a stable, supported, and well adopted library. With that in mind, what do we do until such a situation arises? We can and will work to make OpenSSL a better library, but no matter what we do, we’re in for a long and bumpy ride. I do think that we would benefit from an OpenSSL replacement, but we first need to come to terms with this information and understand that this won’t simply make all of our problems disappear.
While the reality is pretty gloomy, there are some really great things that would come from an OpenSSL rewrite. The opportunity to start fresh knowing what we know now could help prevent some terrible default configuration issues, and potentially even create a better “secure by default” system. There’s a lot of research opportunity and we could benefit greatly from academic assistance. If such an opportunity ever arises to create the next generation OpenSSL, I will gladly lend my keyboard.
Get the latest Software Integrity news, thought leadership, and more.