SSL implementations have been discussed a lot lately, due to Chrome's potential of switching off NSS (https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/preview?pli=1&sle=true#) and OpenSSL with Heartbleed.

What are the major factors preventing someone with tons of resources (e.g. Google) from implementing a new SSL library that is more easily auditable/maintainable to ensure security in the future?

I understand an SSL implementation may be a huge project in itself, but other people have implemented clean room implementations before (e.g. BouncyCastle in Java). So surely someone with enough resources would have the ability to write from scratch, and it would be cheaper than trying to audit and maintain something like OpenSSL.

  • One of those Schneier rules. You come up with an amazing, new, efficient encryption standard to replace those 40 others who are showing their age. Congratulations, you now have 41 encryption standards... So the new implementation will just be another one in a list in the end. Apr 11, 2014 at 3:39
  • The main reason? The current SSL specification standard isn't flawed. How its implemented in specific cases is flawed. There is a difference. Besides if people used Perfect Forward Secrecy this wouldn't be a problem. The big guys actually already do, except Yahoo, but Yahoo also transited everything within their network in plain text until a few months ago.
    – Ramhound
    Apr 11, 2014 at 4:37

1 Answer 1


Writing a working SSL implementation is not hard when you do it often; I have done it four times already (for various customers, nothing opensource, alas). It takes about 3 days, maybe 4 or 5 if you want to do it correctly (at least that what it takes me)(*).

Producing a new SSL library would not be a problem, and neither would it be a solution. There already are several beyond OpenSSL, e.g. GnuTLS, PolarSSL, CyaSSL... See the Wikipedia page for a list. Most are open source.

What is hard is maintenance. It is the tiresome job of keeping the library up to date with new protocol versions, new features, interoperability issues (the workarounds needed to talk with other existing libraries which do not necessarily conform to the standard)... OpenSSL source code is sure hard to read, but that's because it has grown from an historically simple but ancient core, and developed extensions, new APIs, and creeping featurism, including a fair share of "fixes" to avoid compiler bugs.

(*) Excluding the full-featured X.509 validation. Path building, processing of all extensions, and handling of revocation, is quite a task. A primitive validation mechanism for specific cases is easy enough, but reasonably complete X.509 support is daunting. I would not like to implement such a thing in C.

  • +1 on the maintenance. Something along the lines of it's easy to do encryption, getting it right is extremely hard. Apr 11, 2014 at 3:41

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .