SSL Implementations, Code Quality and Common Sense

The far reaching consequences of the Heartbleed vulnerability have been discussed at length in a thread on Bruce Schneier’s blog. In response to a comment on the code quality I wrote the following:

“I nodded in agreement so hard [at another user’s comment on OpenSSL code quality] I might have to see a chiropractor.

OpenSSL’s src is a mess. If cyaSSL can mirror its basic functionality and do such a thing with code that is both legible and importantly it is advertized as 20 times smaller than OpenSSL. Of course it is targeted towards the embedded market but I would rather audit a significantly smaller codebase that a lay sysadmin can likely understand than try and analyze the Pandora’s box that is OpenSSL’s source. It really is a disgrace.

Feature creep is a terrible thing. Security critical libraries should focus on their task. At least move redundant or niche usage extensions and other foolery out of the core and disable them unless uncommented in the Makefile at compile time.”

Now, of course I wouldn’t see a chiropractor. All scientific evidence points to the practice as ineffective folk medicine. But I digress. The point of my post is to highlight the (perhaps obvious) fact that as a library grows and more lines of code are written, so too does the potential for a potentially catastrophic bug to occur.

Good programming in the true style of our BSDite forefathers focuses on a few key laws, and these hold true regardless of what you are coding and what language you happen to be coding in. Essentially these boil down to the KISS principle – write good, well commented code and code with grace. What can be done in five lines may be done in one, but only if this does not negatively affect the readability (and thus the ability of others to audit) of your code. Extending upon this, be sure to separate out any unnecessary fluff from your core code. A feature that is used by perhaps one percent of your users should not be compiled in by default, especially in the case of a security critical library. The final tip is to sanity check everything and always distrust information pulled from external sources (i.e. the foreign host).

Of course all of the above is common sense. Unfortunately this has been lacking in many open source projects, and has been an issue ever since Stallman wanted EMACS to be everything including the kitchen sink.

Advertisements

2 thoughts on “SSL Implementations, Code Quality and Common Sense

    • I don’t mind people taking things off topic so long as they keep it vaguely IT related. 🙂

      I agree wholeheartedly regarding autotools and very much respect the work and opinions of Kamp as an avid FreeBSD user since the early days (Linux is just too passé hah).

      I see the OBSD people want to break down OpenSSL and fix it up. While admirable I don’t think we need a fork or indeed a “new” TLS library. We have plenty and there are many out there that don’t suck. Mozilla NSS and GNUTLS for example…

      If one wanted to start with the bare bones and build a more fully functional SSL library then perhaps an embedded library like wolfSSL or polarssl would be a good starting base. I have personally used the former in a project and the code is clean and easy enough to understand.

      OpenSSL should just die.. Period.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s