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.