OpenSSL: Fix or rewrite?

The list of major OpenSSL security issues keeps growing. Is it better to continue hardening the library? What would it take to rewrite OpenSSL from scratch?

Today’s OpenSSL bug adds another tally onto the rapidly growing list of major security issues with the OpenSSL library. A friend and former colleague, Mike Nygard, asked a very important question.

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?

I would let @abedra build me a secure thing any day @dberkholz @xthestreams @mtnygard @gsoc @sfjacob

—Gary McGraw (@cigitalgem) April 7, 2014

While flattering, I think that Gary’s comment deserves to be evaluated. So let’s talk about what it would take to start from scratch with a library like OpenSSL.

The players

There’s a 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:

The BDFL (benevolent dictator for life)

Say what you want about this tactic, but 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.

Package maintainers

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.

OS/Arch experts

Cross OS compatibility is hard, and we will need people who understand the intricacies of all the major OSs and CPU architectures. With the likely implementation language still C, this knowledge will be essential. And because ARM and other alternative architectures becoming more and more popular, proper knowledge will be required. There are also many embedded devices that use OpenSSL.

Builders

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. So 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.

Breakers

A team of people needs to be dedicated to trying to break the library. These people need to understand how to properly test a library like this and in what ways the library can be used.

Software security experts

A team of reviewers needs to ensure that the overall design of the library is free from flaws and that the code is free from vulnerabilities. Like the builders, they need to understand 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.

Cryptographers

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 makes the biggest impact.

Community interfaces

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.

Integrators

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.

Cost

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. 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.

Reality

It’s plain and simple. Even if we were to gather the required people, find the funding to build things 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.

Ending on a positive note

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.

Check my open source for security issues