[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL



At Sat, 12 Jul 2014 14:46:45 +0200,
Toni Mueller wrote:
> On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
> 
> > I'm not really sure what you mean by this.  I'm pretty sure the
> > openssl development team has a pretty good understanding of
> > security and I don't see anybody adding a backdoor in it.
> 
> Ok, but for whatever reason, they have an imho not as shiny track
> record, as has OpenBSD. Which is no wonder, given all the revelations we
> have had recently, but hey, sometimes one has to make a decision.

OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
how isn't OpenSSL part of the OpenBSD track record?

> > I think GnuTLS is actually a better alternative and wish there
> > were more people developing and using it.
> 
> But developing GnuTLS is a full-time job, and then there's the control
> problem with the FSF - you are certainly aware about the problems the
> original upstream ran into when he wanted to break loose from the FSF
> (for a reason I have forgotten). LibreSSL is a much lower-hanging fruit,
> as it is supposed to be mostly, or entirely, plug-compatible with
> OpenSSL. To me, the playing field largely looks like this atm:
> 
>  * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge
>    amounts of work to make significant use of it.

It depends on how you look at it. If you see the OpenSSL API as
something that isn't really well designed then other libraries not
copying the API is actually a good thing.

>  * MatrixSSL, which once had a dubious license, and which still did not
>    come out too well in the SSL lib comparison I recently saw (see the
>    list archive),
>  * the now newly staffed OpenSSL project, with their mixed track
>    record (eg. "FIPS"), and now
>  * LibreSSL, which sounds much like an OpenSSL on a diet, and with some
>    exercise, and promising thrust behind it, but mostly simply a
>    drop-in.

You forget one of the big problems with OpenSSL that LibreSSL doesn't
fix: the license. It actually makes the mess even bigger, given that
some of the GPL exceptions only talk about "the OpenSSL library" and
don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in
for OpenSSL we can't replace OpenSSL with LibreSSL for those projects.

You also forget to list two other TLS libraries:

* NSS, in my opinion the biggest downside of NSS is that it includes
  NSPR. This both increases the code size a lot and makes the API less
  nice if I remember correctly.

* PolarSSL, which I really like from a technical point of
  view. Featurewise it is pretty complete (the only major feature it
  doesn't implement is DTLS AFAICS), while being one tenth the size of
  OpenSSL / GnuTLS:
  https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies
  PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version
  that is used by the Dutch government.
  The downsides are that it looks like it doesn't have a stable API
  and contributing needs copyright assignment because it is
  dual-licensed.


Kind regards,

Jeroen Dekkers


Reply to: