* PolarSSL seems to be very clear code, well modularized and a much more sane API than OpenSSL.
* Supports setting cipher orders by TLS version.
* Cipher support is good (all the new ECC and SHA2 stuff is included), but it doesn't support SSLv2 or EXP ciphers (I'm counting this as a "pro", though).
* Not quite as much support for working with X509 certificates. It parses the extension fields it knows about, but if you want to know more than those, you'll have to dig into ASN.1 yourself.
* Related to the previous point: I couldn't find support in converting different ASN.1 string formats. Probably will have to depend on another library to do that.
* I found a buffer overflow bug within a few hours of working with it , which is really not a good sign for a TLS library. However, it did get acknowledged within 24 hours (I've got an OpenSSL patch which has been sitting on their bugtracker without any reply for 6 months).
* Setting a different curve for ECC requires a compile time flag to be set, which is disabled by default.
* Using the server's cipher order or the client's is also a compile time flag, can not be set at run time.
 = https://github.com/polarssl/polarssl/issues/83
There are worse things to try to implement than ASN.1, but they are mostly related to timing, crypto or memory re-use.
The library as a whole was relatively well documented and pleasant to use. I am not going to even pretend to be enough of a crypto expert to have my own opinion of its security quality, though.
EDIT: I suppose I should add, for completeness, that we eventually decided to use GnuTLS for our TLS plugin implementation. Just in time to catch the latest GnuTLS security problem, but we avoided heartbleed.
GnuTLS was not the most pleasant API to use, but it did hit some very impressive throughput numbers in our use cases, and seemed to deliver on the theoretical promised instructions/byte that Intel talks about in their whitepaper(s) about AES-GCM.
I quit gradschool a month after publishing this so can't comment on what Suman is currently working on, but it looks like it is still mostly my code for generation.
I didn't write the script for using polarSSL but I wrote most the other ones,the testing harness, cert generation and cert crawling, and I can say that polarSSL loved to crash on my weird certs. I almost wanted to remove them from the tested list for being so unreliable.
It's the first one, Frankencert.
You can see some screenshots at http://blog.frama-c.com/
but unfortunately their frama-c annotations for polarssl are not open source. It would help a lot if such annotations could be used for similar crypto APIs also.
There are many more such symbolic verifiers and bugfinders out there (using solvers), but Frama-C was one the first and is still one of the best.
Another possibility is that the person who found the memory corruption was not using PolarSSL in the same configuration as the one described in the verification kit. PolarSSL allows to select sub-components at compile-time, and to select between implementation options within these components. Finally, there is always the possibility that a bug remains for compilation parameters other than the ones the verification was configured for. If I did not do too bad a job, this comment should make it clear what kind of differences could explain a bug remaining: https://news.ycombinator.com/item?id=7573483
There is always the possibility of a bug in Frama-C having for consequence a bug in PolarSSL not being found. This is far less likely than the previous commenter referring to a version that was not verified.
Yes, Privacy Enhanced Mail is not part of the verified PolarSSL configuration. And the bug at https://github.com/polarssl/polarssl/issues/83 is definitely the sort of bug Frama-C would “not shut up” about, as Regehr puts it. The warning will only occur where the buffer overflow eventually happens, and it may be more or less pleasant to go back from the site of the buffer overflow to the bug in the fashion of http://blog.frama-c.com/index.php?post/2014/02/23/CVE-2013-5... , but Frama-C's value analysis is designed to reliably find this bug and not shut up about it.
It is more a choice of version, choice of compilation platform (some bugs only occur with 64-bit pointers or unsigned chars —the verification in question has been done with 32-bit pointers and signed chars, no guarantee is given for other parameters) and description of a library configuration.
The PolarSSL Verification Kit takes the form of a 8-page description of the above parameters and a 100-page technical annex with all the formal specifications and justifications. You only need to read the second part if you don't trust the kit's authors. Like similar documents are, the technical annex is intended to be audited by picking a piece at random and checking the reasoning locally and how it relates to the other pieces.
The recent OpenSSL bug is a great reminder that we shouldn't just used OpenSSL because it's what everyone else uses. It's an excuse for use to investigate alternatives and then make a rational decision about which implementation to use. If that investigation leads us back to OpenSSL, then so be it. But without looking into competing libraries, any talk about OpenSSL being the better stack is pure speculation.
They only accept copyrightable contributions from people with that agreement (as far as I know)..
As typo fixes, small bug fixes and one-liners are not considered copyrightable they accept those without it..
I'm just missing CPU specific optimizations (SSE, Altivec, ...)
The biggest problem with OpenSSL is that noone helps.
...it really isn't that simple. Many of the mechanisms for obligating commercial entities to give back simply result in those entities ignoring a project from the start. Plenty of projects that don't enforce that obligation receive significant commercial support.
It would make some sense to backtrack to the last BSD-licensed PolarSSL release and work from there.
There are some projects attempting to do so: https://gitorious.org/tropicssl
Like all the code I've contributed with no reciprocation demanded.
This argument is old, BSD vs Linux old since the 1990s.
I guess you are using BSD kernels, runtimes and compilers on your phones and super-computers too?