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

by laumars • 12 years ago

51 47 12 years ago

karavelov• 12 years ago

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.

aroch• 12 years ago

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

teacup502• 12 years ago

The other side of the license is commercial.

teacup502• 12 years ago

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

cryptodude5• 12 years ago

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

nly2• 12 years ago

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.

fpx• 12 years ago

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

maxerickson• 12 years ago

Source is paper here:

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

It's the first one, Frankencert.

dfc• 12 years ago

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

pencilo• 12 years ago

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.

darklajid• 12 years ago

(stolen from the amazing prosody guys):

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

cryptodude5• 12 years ago

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

subbz• 12 years ago

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.

stronglikedan• 12 years ago

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.

laumars• 12 years ago

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.

rodgerd• 12 years ago

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?"

mst• 12 years ago

Monocultures have their own risks.

arvidj• 12 years 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/

cryptodude5• 12 years ago

Can you explain what that means?

nly2• 12 years ago

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

rurban2• 12 years ago

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.

tptacek3• 12 years ago

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.

pascal_cuoq3• 12 years ago

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.

aethertap• 12 years ago

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.

xnyhps• 12 years ago

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

tptacek3• 12 years ago

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

dsr_• 12 years ago

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.

itp2• 12 years ago

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.

cryptodude5• 12 years ago

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

itp2• 12 years ago

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.

Hello71• 12 years ago

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

vamega• 12 years ago

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.

qwerta• 12 years ago

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.

cryptodude5• 12 years ago

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

rurban2• 12 years ago

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

justizin• 12 years ago

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.

awj• 12 years ago

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.

mzs• 12 years ago

The biggest problem with openssl is they ignore bug reports.

bearbin• 12 years ago

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.

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

Related Stories