OpenSSL 1.0.0 released [LWN.net]

OpenSSL 1.0.0 released

Posted Mar 30, 2010 3:49 UTC (Tue) by njs (subscriber, #40338)
In reply to: OpenSSL 1.0.0 released by flewellyn
Parent article: OpenSSL 1.0.0 released

Also NSS, which the Fedora people seem to be attempting (slowly?) to standardize everything on: http://fedoraproject.org/wiki/FedoraCryptoConsolidation

to post comments

OpenSSL 1.0.0 released

Posted Mar 30, 2010 10:12 UTC (Tue) by buchanmilne (guest, #42315) [Link] (3 responses)

But it is not suitable for software which must simultaneously support client
and server operation, as it (apparently) only supports one SSL context.

This is the reason it hasn't been considered for OpenLDAP.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 18:46 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

Yet NSS is the crypto library used in the 389 Directory Server (aka Redhat Directory Server, formally Fedora Directory Server; derived from the netstcape directory services...). So somehow it's appropriate for that LDAP server even though the OpenLDAP folks do not like it.

NSS is also FIPS140-2 certified. The only other open source software that has gotten it is OpenSSL. So that makes it appropirate for any sort of institution that has to work with the USA federal government. Not terribly important for most people, but at least you know it's been verified for correctness by third party experts and this certification is critically important for companies like Redhat.

it's very mature library. It's been around for a long time. Supports hardware acceleration, smart cards, and a bunch of other little things that OpenSSL does not. (and there, are, of course things that OpenSSL supports that NSS does not)

The license is a lot better, also. NSS is triple licensed under the MPL, GPL, and LGPL giving it superior license compatibility over OpenSSL or GnuTLS.

It also has very nice python bindings that Redhat put a lot of effort into. This allows you to use Python with SSL support in GPL'd applications... which by default you technically cannot since python's normal ssl stuff is OpenSSL derived.

There is some detail in the API design that is suppose to be superior for application developers. Something about keeping the crypto aspect of things out of the hands of the application developers... which is generally a good thing since app developers rarely get that sort of thing correct. But I don't know enough to really understand everything and talk about it much. Just what I've read in the past.

Personally, I feel if everybody decided to follow Fedora's example and standardize around a NSS then we'd all be better off. Having lots of different crypto libraries is just asking for trouble since it's surprisingly difficult to get crypto right.

But actually I do end up using OpenSSL a lot more then NSS because of the nice command line client and ample online examples of OpenSSL usage. So I am not trying to knock the work the OpenSSL folks have put into it.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 18:54 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Red Hat is leading this effort but it is worth noting that LSB is standardizing
on NSS as well

https://ldn.linuxfoundation.org/node/5576

FIPS and GPL compatibility being two important driving factors.

OpenSSL 1.0.0 released

Posted Mar 31, 2010 15:14 UTC (Wed) by TRS-80 (guest, #1804) [Link]

OpenLDAP ships client libraries as well as an LDAP server, and that's where the problem with NSS is. What happens when a program links against NSS and also links against libnss-ldap that's linked with NSS? NSS' lack of context support rules it out. The OpenLDAP server can also be an LDAP client through back-ldap and so has the same problem. It's not like the NSS developers don't realise this is a problem, they've defined functions to allow different contexts, but the functions are stubs that just return.