Technical Debt and Security: time to move on from OpenSSL?

I am about to give up on OpenSSL and start supporting LibreSSL instead. OpenSSL is sinking, and folks behind LibreSSL understand that good security starts with good engineering principles. Here is a glimpse into the heart and soul of the argument, courtesy of OpenSSLRampage.org.

One day, OpenSSL folks decided to avoid their own API. To quote  LibreSSL developers:

“Someone (TM) thought it was smart to save memory by using malloc(1) and manual field fiddling to create an ASN1_INTEGER object, instead of using M_ASN1_INTEGER_new() which will allocate sizeof(long) bytes. That person had probably never looked into malloc(3) and never heard of allocation size rounding.”

Here is the original OpenSSL code:

And here is the LibreSSL version:

See the full GitHub patch here

Was that specific code related to this week’s slew of OpenSSL CVEs? No. However, the mindset is. Putting forth an API in place for everyone, and then refusing to eat your own dog food is not good. Especially in the long run.

The issues are no longer hypothetical though. This week’s high severity OpenSSL security vulnerabilities appear to be rather limited for LibreSSL, thanks again to sound engineering principles.

I am encouraged to see that the renewed focus on the funding and participation in the OpenSSL project is helping – the last round of vulnerabilities were discovered during the security audit of their codebase. And that’s fantastic. However, what’s disappointing is the lack of any significant action from the OpenSSL team towards simplification and the painful but necessary process of shedding the bloat and dealing with the technical debt right now. I feel it’s getting to be too late…

Yes, LibreSSL is still new. I will not be surprised if in the future there will be issues related to an overzealous cleanup. But so far the common sense and sound engineering are showing good results. Ignoring technical debt, on the other hand, is a bad business decision.