OpenSSL: Fix or Rewrite?

by Aaron Bedra on Tuesday, April 8, 2014

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

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.

Let’s talk about what it would take to start from scratch with a library like OpenSSL.

The Players

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:

The BDFL (Benevolent Dictator For Life)

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.

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

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

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

Reality

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.

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.

4 Responses to “OpenSSL: Fix or Rewrite?”

  1. […] whether or not OpenSSL should be patched up or completely rewritten. The realities of doing so were recently analyzed by one Aaron Bedra, a consultant with Cigital, but now a third idea has been […]

  2. Aaron Bedra says:

    I would love to put this through a QRM framework. The thought crossed my mind but I realized that I didn’t have enough information to do it justice. A consortium would be great, and I think there’s a willingness among some of the larger companies to make that happen, but someone still needs to lead the charge.

    On point the first, I do hope it isn’t C, I am just having a hard time understanding what would take over. While there are front runners in the ML camp (Haskel, OCAML, etc) they introduce a different set of problems with understanding of the language and lazy evaluation/side channel attacks. I also have hopes for erlang and things like gambit scheme, but again, it’s about cross platform compatibility and who can contribute. I want nothing more in this situation for the successor to not be C.

    On the second point, there has been some traction here. There are some competing implementations, and some positives have come out of them. It seems like the community is still in full support of OpenSSL though. There might be something to salvage from all of what is currently out there into a new library. It might at first just be picking and choosing good ideas and packaging them, but I can’t say for sure. A lot of smart people have worked to solve this problem in different ways. I think it’s down to applying some good old fashioned engineering and discipline to drive us into the next wave. I would love to try the QRM framework and have a real discussion about what other languages could solve this problem though and see where we end up.

    *Spoiler alert* it’s not C++ :)

  3. Aaron Bedra says:

    That was a great read, thanks Alex!