Should we settle on one SSL implementation?

[Daniel P. Berrange]

On Mon, Oct 22, 2007 at 08:17:01AM -0400, Bernardo Innocenti wrote:
> I remember this topic being discussed some time ago,
> but software is fluid and maybe it's time to respin
> the topic.
> 
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.
> 
> We're now shipping no less than 4 different implementations
> of SSL:
> 
> - openssl (OpenBSD's implementation)
> - nss (Netscape's implementation)
> - gnutls (LGPL implementation)
> - puretls (Java implementation)
> 
> But which one should replace the others?
>
> It is not clear to me.  Judging from dependencies, OpenSSL,
> NSS and gnutls all seem equally popular in Fedora.

Which is pretty much where your problems start. Re-writing applications to
switch from one impl to another is seriously non-trivial. There is no way
in the world you'd want to carry such patches in the Fedora packages because
they'd be a huge maintainence time sink whenever a new upstream release came
out. So getting any port accepted by the upstream application author has to
be the number 1 priority. To do that you need rather compelling reasons to
convince the upstream authors. And there is new software coming out all the
time using any one of these libraries. IMHO converging on 'one true impl' 
of SSL is an pretty intractable problem unless someone wants to throw alot
of their personal developer time at porting & submitting & merging upstream.

> If we are to believe a non-independent comparison, gnutls
> looks like the best choice:
> 
>  http://www.gnu.org/software/gnutls/comparison.html
>
> I couldn't find good benchmarks around, but they would
> make an important decision factor.

The definition of 'best' is rather in the eye of the beholder. The GNUTLS
guys will say theirs is best because it has most complete SSL spec coverage.
The NSS guys will say theirs is best because it has the FIPS certification
and can interact with smart card readers (you know, that pcscd daemon which
spins burning your CPU time just in case you ever insert a smartcard). The
OpenSSL guys will say, well who knows ?!?!

As an app developer I'll say GNU TLS has the most pleasant API to deal
with, particularly since it doesn't try to hide POSIX behind a abstraction
layer. As a sysadmin GNU TLS certtool is far more pleasant 'openssl' tool.

> There are two good reasons not to choose OpenSSL: the
> license is GPL incompatible and the ABI gets broken by
> upstream very frequently.  Strangely enough, OpenSSL in
> F8 is linked against nss instead of openssl.

Yep, any GPL apps using OpenSSL without an explicit exception need to be
fixed, but aside from that its hard to get excited about porting SSL libs.
The ABI breakages are likely encouraging any new upstream apps to avoid
OpenSSL in favour of GNU TLS too.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|