In the world of security everything resolves around trust. This naturally also applies to the PolarSSL SSL Library.
Since the 'Heartbleed bug' we receive an increased number of questions like:
- Can I trust this source code?
- How do I know your SSL library does what it claims to do?
- Who made PolarSSL?
- Are there any backdoors built in?
- Are there any (known) security vulnerabilities?
- Can the NSA or any other secret service read my communications when I use PolarSSL?
All these are understandable questions. Even more so with all the recent news about backdoors inserted by secret services, and critical security bugs in large security software such as OpenSSL and GnuTLS.
So we do our best to provide you with as much assurance we can give on the website. This post touches all different aspects that can provide assurance and trust in our SSL library!
We have a high interest in developing secure software. We are not a group of volunteers that spend some of their spare time helping an open source project. All core developers are paid and do this as a job. We're all perfectionists and we want to get things right!
At the time of writing the core team consists of:
- Paul Bakker, known as pjbakker on Github
Before becoming the lead developer for PolarSSL, Paul has been an architect and lead developer for high-security products.
- Manuel Pégourié-Gonnard, known as mpg on Github
Manuel joined PolarSSL after completing his PhD, and has been the initial developer of the Elliptic Curve modules. Aside from being a great PolarSSL developer, he has a knack for finding corner cases and writing intricate tests to cover them.
Our SSL library's development process is structured so that external change are at least reviewed ("ACK'ed") by two core developer. Patches by other core developers are reviewed by at least one other core developer.
We always make sure that compiling the library (with gcc and Clang) produces no warnings or errors. And we do have a reasonably large set of warnings enabled. In particular, Clang's
-Wunreachable-code which prevents analogues of Apple's recent "goto fail" to go unnoticed.
Lean and mean
Our modularity and configurability helps as well. PolarSSL is very modular, up to the level where you can enable or disable a lot of non-core runtime features at compile time. The fact that it's relatively easy to create custom compact configurations is a security advantage as well. Less compiled and thus active code, means a smaller attack surface, and thus less chances of bugs and vulnerabilities.
Another advantage is that our SSL library is Open Source and people can look at our code. Yes, we know this is no silver bullet. The recent OpenSSL and GnuTLS issues have shown everyone that "Open Source != Secure". It does help though. PolarSSL is often used by security researchers in reviews. And each review helps increase the level of security a bit more.
Additionaly, the PolarSSL code is automatically and manually tested at each change.
More information on our automated tests can be found in the article on what tests and checks are run for PolarSSL.
In short this includes:
- Compilation on different systems
- Code coverage
- Regressions, test vectors, corner cases
- Interoperability with other SSL libraries
- Different build configurations
- Memory leak checking
- Memory integrity checking
Aside from what we can do ourselves, external parties also provide additional assurance for PolarSSL.
Formal verification by TrustInSoft
PolarSSL has been formally verified in a specific configuration by TrustInSoft using the Frama-C framework. You can get more information on the PolarSSL Verification Kit from them.
Government accreditation within OpenVPN-NL
PolarSSL is used (instead of OpenSSL) as the cryptographic core in OpenVPN-NL. The Dutch government and Fox-IT have performed code reviews of the PolarSSL source code for that accreditation.
Coverity via Travis-CI
We do not believe that software can ever be totally bug-free. There are so many different operation systems with different standards and compilers with non-standard behavior that there will always be issues in the code. The fact that most protocols and standards are complex and parts of them are open to different interpretations, doesn't help either.
We do our best to make sure that these issues do not affect the security of the PolarSSL library.
Do you think there is more that we can do to improve the trust in the PolarSSL SSL library? Please let us know!