PolarSSL – Does anyone have any experiences with this OpenSSL competitor? | Hacker News Reader

PolarSSL – Does anyone have any experiences with this OpenSSL competitor?

polarssl.org

51 pointslaumars47 comments

I've been looking into what options exist and what their pros and cons are for switching LuaSec from OpenSSL to something else (mostly in the context of Prosody's TLS support). These are my pros and cons so far, but it's a pretty specific application, so not all points may be important for others.

Pros:

* 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).

Cons:

* 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 [1], 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.

[1] = https://github.com/polarssl/polarssl/issues/83

Weird, considering that there's a commercial version of PolarSSL verified with FRAMA-C that contributed its findings back to the open source project.

Go ahead and search the net for ASN.1 parser vulnerabilities. I won't wait; you'll be compiling quite a list.

There are worse things to try to implement than ASN.1, but they are mostly related to timing, crypto or memory re-use.

We evaluated PolarSSL at FoundationDB while adding TLS support to our 2.0 release. In the end I think our primary deciding factor was a lack of support for hardware accelerated AES-GCM using AES-NI and PCLMUL on modern hardware, although I understand they are working on it.

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.

I saw they added AES-NI support in PolarSSL 1.3.3 just before the start of this year..

Oh, that's great news! Unfortunately I'm on other projects now and likely won't have a chance to reevaluate in the short term, but I'd like to take a look at some point.

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.

There is a chart (unfortunately without source) going around comparing different SSL implementations. In this chart there are situations in which PolarSSL accepts a certificate when it should not.

http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large

Source is paper here:

https://www.cs.utexas.edu/~shmat/index.html#pub

It's the first one, Frankencert.

From: Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations

https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf

github: https://github.com/sumanj/frankencert

The code used for the paper is actually here: https://github.com/pencilo/ssl

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.

(stolen from the amazing prosody guys):

https://github.com/polarssl/polarssl/issues/84

Which they just released there fix for in 1.3.6.. (Floated by on Twitter a few minutes ago)

Also check out the PolarSSL Verification Kit[1], a FRAMA-C verified version of PolarSSL.

[1] http://trust-in-soft.com/no-more-heartbleed/

Can you explain what that means?

Looks like a fork that's gone through static analysis.

It is not really a fork: all the necessary bugfixes to make the chosen PolarSSL version free of undefined behavior have been contributed back and either have been released or are pending release.

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.

This should be the major argument against GnuTSL and OpenSSL. PolarSSL is symbolically verified!

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.

I wonder how to reconcile the symbolic verification of PolarSSL with FRAMA-C with the top comment on this thread, where someone evaluating PolarSSL found a memory corruption flaw within a day of looking at it.

The most likely explanation is that the memory corruption flaw was found in a different PolarSSL version than the one the verification kit applies to. The PolarSSL verification kit is a recent development. The available verification kit applies to version 1.1.8 with patches that have not been released yet. Another verification kit is being finalized for the 1.3.x branch.

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.

It should be pretty easy to verify which case it is: acquire the verified version of PolarSSL and check to see if the memory corruption bug, found 2 days ago and reported publicly, is in that codebase.

Oh, there is a link for the bug. Sorry, my bad.

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.

Everybody who is dropping OpenSSL in favor for alternative library X is going to bet on the wrong horse here. A big leak has just been fixed in OpenSSL and every commit will be checked now by more critical eyeballs than before imho.

I don't believe that the presence of the vulnerability is the reason people are looking to migrate. I believe that the discovery of this vulnerability shed light on the code quality of OpenSSL, and that is what is turning people away. Some people have only recently learned of the quality issues, and have lost trust in the project. Others have known about them, but have been begrudgingly dealing with them, and this was the straw that broke the camels back. There's always someone looking to migrate to a different implementation, and all they need is a good reason to justify the effort.

That maybe true, but you're also making the assumption that other SSL/TLS implementations are not already better.

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.

This sounds dangerously close to a variation on the sunk costs fallacy. "Why abandon this code base when we're putting so much effort into it?"

Monocultures have their own risks.

How can they sell an exception to the GPL license if they're accepting Pull Requests on Github. I haven't seen any reference to a CLA.

Make sure you read their license, it could be slightly modified GPL. Some licenses (such as Apache 2) has clause which makes any contribution Apache licensed.

I have signed a Copyright Sharing Agreement with them...

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..

Their test system knows about valgrind and ASan and runs it if available. There's also a frama-c annotated version. not open source, but still this is exceptional.

I'm just missing CPU specific optimizations (SSE, Altivec, ...)

http://curl.haxx.se/docs/ssl-compared.html

PolarSSL condones the practice that makes OpenSSL less secure than any other, which is commercial entities not being obligated to give back. They simply extend that privilege to people who include it in a commercial product.

The biggest problem with OpenSSL is that noone helps.

> PolarSSL condones the practice that makes OpenSSL less secure than any other, which is commercial entities not being obligated to give back.

...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.

The biggest problem with openssl is they ignore bug reports.

I don't know personally, but the project I work on (MCServer, an open source Minecraft server) implemented it as a replacement to CryptoPP recently (we needed SSL support with a sane license) and it has been working fairly well. Even when a feature we needed wasn't implemented, the maintainers quickly added it and were nice to work with.

I used it with a small embedded system a couple of years ago and was generally very pleased with it, at least from an ease of use perspective. For the niche I was filling it was a great fit. I don't know how well it adheres to the standard though, or whether it has known vulnerabilities.

I have no experience with PolarSSL but it is under GPL so unless your code is under GPL also it is a no-starter. I suppose this is a major obstacle for wider adoption.

Its dual-licensed, you can use their non-GPL licensed code

The other side of the license is commercial.

Which is normally not a problem if you're creating a commercial product. You can also get a license for FOSS projects if the GPL isn't suitable.

Oh so you want it for free? And without giving back your work to the public?

Oh.

Oh, yes.

Like all the code I've contributed with no reciprocation demanded.

Well then keep using those kind of licenses, and openssl, and we the others will gladly use GPL kind of licenses, and move to gnutls and/or polarssl.

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?

Admittedly, OpenSSL's Apache license allows for that usage case, so it's technically a fair question when comparing alternatives.

PolarSSL forked from BSD-licensed XySSL (no longer maintained) in 2008.

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

They have a standard FOSS License Exception allowing you to use it with all the regular Open Source licenses..

Link: https://polarssl.org/foss-license-exception

It depends. The GPL doesn't have an effect if your software is never distributed outside of your organisation e.g. if it's only ever used server-side.

Reply on news.ycombinator.com