1:12 p.m.
The recent trouble in ITS#5361 prompted me to look into the GnuTLS code a
little deeper. It turns out that their corresponding set_subject_alt_name()
API only takes a char * pointer as input, without a corresponding length. As
such, this API will only work for string-form alternative names, and will
typically break with IP addresses and other alternatives.
Looking across more of their APIs, I see that the code makes liberal use of
strlen and strcat, when it needs to be using counted-length data blobs
everywhere. In short, the code is fundamentally broken; most of its external
and internal APIs are incapable of passing binary data without mangling it.
The code is completely unsafe for handling binary data, and yet the nature of
TLS processing is almost entirely dependent on secure handling of binary data.
I strongly recommend that GnuTLS not be used. All of its APIs would need to be
overhauled to correct its flaws and it's clear that the developers there are
too naive and inexperienced to even understand that it's broken.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:55 p.m.
<quote who="Howard Chu">
The recent trouble in ITS#5361 prompted me to look into the GnuTLS
code a
little deeper. It turns out that their corresponding
set_subject_alt_name()
API only takes a char * pointer as input, without a corresponding length.
As
such, this API will only work for string-form alternative names, and will
typically break with IP addresses and other alternatives.
Looking across more of their APIs, I see that the code makes liberal use
of
strlen and strcat, when it needs to be using counted-length data blobs
everywhere. In short, the code is fundamentally broken; most of its
external
and internal APIs are incapable of passing binary data without mangling
it.
The code is completely unsafe for handling binary data, and yet the nature
of
TLS processing is almost entirely dependent on secure handling of binary
data.
I strongly recommend that GnuTLS not be used. All of its APIs would need
to be
overhauled to correct its flaws and it's clear that the developers there
are
too naive and inexperienced to even understand that it's broken.
So that means OpenLDAP on Debian is still not recommended if you don't
compile your own OpenSSL and OpenLDAP.
2:27 p.m.
Gavin Henry wrote:
<quote who="Howard Chu">
> I strongly recommend that GnuTLS not be used. All of its APIs would need
> to be
> overhauled to correct its flaws and it's clear that the developers there
> are
> too naive and inexperienced to even understand that it's broken.
So that means OpenLDAP on Debian is still not recommended if you don't
compile your own OpenSSL and OpenLDAP.
Since they're committed to using GnuTLS, yes. Unfortunately for the Debian
community, just because software is released under the GPL doesn't say
anything about its quality.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:44 p.m.
Howard Chu <hyc(a)symas.com> writes:
Since they're committed to using GnuTLS, yes. Unfortunately for
the
Debian community, just because software is released under the GPL
doesn't say anything about its quality.
GnuTLS is used in Debian for libldap because the project believes that
it's the only thing that it can do legally under the project's copyright
law interpretation (without kicking out all the GPL software that directly
or indirectly links with libldap), not because we have a preference for
GPL software. Many people in Debian do not (myself included).
Personally, I release all my stuff under the MIT license.
Other distributions disagree with the copyright law interpretation. Some
lawyers apparently agree and others don't. Given that I'm neither a
lawyer nor willing to pay the money to hire one for the project, and given
that no one really cares about my opinion of Debian's copyright analysis
anyway, it is what it is. Convincing me that Debian's position is wrong
is essentially pointless. I can't change it. Convincing Eben Moglen that
it's wrong might accomplish something.
It's frustrating for me too. The fault here lies with the combination of
the obnoxious GPL refusal to cooperate with other licenses and the
obnoxious OpenSSL advertising clause, or arguably with Debian's extremely
conservative position on licensing with dynamic linking, but that's a
fight that I have no desire to take on yet again.
There are enough other reasons to use already-packaged software and enough
reasons to use Debian in preference to other distributions (for what we're
doing at Stanford; I'm not interested in discussing that position with
anyone on this list) that it was worth helping fund the development of the
GnuTLS support. That support basically works, recommended or not, which
is a better place than we were in before. I can only hope that it will
get better in the future, or that some miracle will happen with either
OpenSSL licensing or Debian's legal interpretation of copyright, none of
which I have any real control over.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
2:35 a.m.
On Sat, 2008-02-16 at 14:44 -0800, Russ Allbery wrote:
Howard Chu <hyc(a)symas.com> writes:
> Since they're committed to using GnuTLS, yes. Unfortunately for the
> Debian community, just because software is released under the GPL
> doesn't say anything about its quality.
There are enough other reasons to use already-packaged software and
enough
reasons to use Debian in preference to other distributions (for what we're
doing at Stanford; I'm not interested in discussing that position with
anyone on this list) that it was worth helping fund the development of the
GnuTLS support. That support basically works, recommended or not, which
is a better place than we were in before. I can only hope that it will
get better in the future, or that some miracle will happen with either
OpenSSL licensing or Debian's legal interpretation of copyright, none of
which I have any real control over.
What would it take to create a third way here with Mozilla's NSS?
For my sanity in Samba4, I keep bugging those involved with NSS and
nss_compat_ossl to create a gnutls-like API to NSS. Some aspects of the
API I like, while other aspects of the GnuTLS implementation drive me
nuts - such as draining and blocking on /dev/random...
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
2:02 p.m.
Andrew Bartlett <abartlet(a)samba.org> writes:
On Sat, 2008-02-16 at 14:44 -0800, Russ Allbery wrote:
> There are enough other reasons to use already-packaged software
and
> enough reasons to use Debian in preference to other distributions (for
> what we're doing at Stanford; I'm not interested in discussing that
> position with anyone on this list) that it was worth helping fund the
> development of the GnuTLS support. That support basically works,
> recommended or not, which is a better place than we were in before. I
> can only hope that it will get better in the future, or that some
> miracle will happen with either OpenSSL licensing or Debian's legal
> interpretation of copyright, none of which I have any real control
> over.
What would it take to create a third way here with Mozilla's NSS?
For my sanity in Samba4, I keep bugging those involved with NSS and
nss_compat_ossl to create a gnutls-like API to NSS. Some aspects of the
API I like, while other aspects of the GnuTLS implementation drive me
nuts - such as draining and blocking on /dev/random...
Development of a port to GnuTLS required changes on both sides, but wasn't
particularly expensive. I expect that a port to Mozilla's NSS wouldn't be
too much more difficult, although of course Howard would be the person to
ask for an estimate.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
12:06 a.m.
Russ Allbery wrote:
Andrew Bartlett<abartlet(a)samba.org> writes:
> On Sat, 2008-02-16 at 14:44 -0800, Russ Allbery wrote:
>> There are enough other reasons to use already-packaged software and
>> enough reasons to use Debian in preference to other distributions (for
>> what we're doing at Stanford; I'm not interested in discussing that
>> position with anyone on this list) that it was worth helping fund the
>> development of the GnuTLS support. That support basically works,
>> recommended or not, which is a better place than we were in before. I
>> can only hope that it will get better in the future, or that some
>> miracle will happen with either OpenSSL licensing or Debian's legal
>> interpretation of copyright, none of which I have any real control
>> over.
> What would it take to create a third way here with Mozilla's NSS?
> For my sanity in Samba4, I keep bugging those involved with NSS and
> nss_compat_ossl to create a gnutls-like API to NSS. Some aspects of the
> API I like, while other aspects of the GnuTLS implementation drive me
> nuts - such as draining and blocking on /dev/random...
I pointed out a number of problems in the GnuTLS design last year when I
started the port. I stated back then that it was ill-advised, given the
library's overall design and maturity. Oh well.
Development of a port to GnuTLS required changes on both sides, but
wasn't
particularly expensive.
It still leaves something to be desired, like better cipher suite APIs, etc..
I expect that a port to Mozilla's NSS wouldn't be
too much more difficult, although of course Howard would be the person to
ask for an estimate.
I would think there are other developers here who are familiar with Mozilla
NSS and can read the code in libldap/tls.c. It's certainly not high on my list
at the moment since OpenSSL works for me. One thing that I find rather
annoying about NSS is its use of a private certificate/keystore that requires
additional tools to manipulate.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:17 a.m.
Howard Chu wrote:
Russ Allbery wrote:
> I expect that a port to Mozilla's NSS wouldn't be
> too much more difficult, although of course Howard would be the person to
> ask for an estimate.
I would think there are other developers here who are familiar with
Mozilla NSS and can read the code in libldap/tls.c. It's certainly not
high on my list at the moment since OpenSSL works for me. One thing that
I find rather annoying about NSS is its use of a private
certificate/keystore that requires additional tools to manipulate.
Well, using Mozilla NSS and its certificate database would have
pros and cons. One pro would be that LDAP clients could make use
of the certificate database, e.g. containing client certs/keys,
already maintained by one of the Mozilla GUI client products (e.g.
Seamonkey). Similar how OpenOffice uses the Mozilla cert database
out-of-the box.
What I find annoying with OpenSSL is that IIRC there is no
separate cert store for intermediate CA certs which are not a
trust anchor. So the server has to be configured to always send
the intermediate CA certs during SSL connect. Would have to
examine this a little bit closer though. Using the NSS cert
database together with certutil maintaing trust flags for certain
cert usage is more powerful in this regard.
I cannot tell how active the development of OpenSSL and Mozilla
NSS are compared to each other.
Ciao, Michael.
9 a.m.
Howard Chu <hyc(a)symas.com> writes:
I pointed out a number of problems in the GnuTLS design last year
when I
started the port. I stated back then that it was ill-advised, given the
library's overall design and maturity. Oh well.
You did, and I do want to be clear that you were heard and we took that
into account, and I really appreciate your willingness to support GnuTLS
to the extent that you can despite your reservations. It was, for us, the
best of a set of bad options. I hope that, in the long run, it will
improve, and I'll do what I can to push it in that direction.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
10:13 a.m.
--On Thursday, February 21, 2008 12:06 AM -0800 Howard Chu <hyc(a)symas.com>
wrote:
> I expect that a port to Mozilla's NSS wouldn't be
> too much more difficult, although of course Howard would be the person to
> ask for an estimate.
I would think there are other developers here who are familiar with
Mozilla NSS and can read the code in libldap/tls.c. It's certainly not
high on my list at the moment since OpenSSL works for me. One thing that
I find rather annoying about NSS is its use of a private
certificate/keystore that requires additional tools to manipulate.
When Stanford was looking at an OpenSSL alternative, Mozilla's NSS was
brought up then. There was a discussion on IRC's #ldap channel about it at
that time, IIRC, and it was found deficient in a number of areas. Not that
I recall what they all were. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
5:16 p.m.
On Sat, Feb 16, 2008 at 01:12:31PM -0800, Howard Chu wrote:
The recent trouble in ITS#5361 prompted me to look into the GnuTLS
code a little deeper. It turns out that their corresponding
set_subject_alt_name() API only takes a char * pointer as input,
without a corresponding length. As such, this API will only work for
string-form alternative names, and will typically break with IP
addresses and other alternatives.
Has this been pointed out to the GnuTLS developers? Or is your
frustration level too high :)
We have an interest in delivering OpenLDAP w/GnuTLS so anything to
make GnuTLS better is something we'd like to see happen.
--
albert chin (china(a)thewrittenword.com)
4:20 p.m.
--On Thursday, February 21, 2008 7:16 PM -0600 Albert Chin
<openldap-devel(a)mlists.thewrittenword.com> wrote:
We have an interest in delivering OpenLDAP w/GnuTLS so anything to
make GnuTLS better is something we'd like to see happen.
yaSSL may be another worthwhile alternative. It does have GPL licensing as
well.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
6:08 p.m.
Quanah Gibson-Mount <quanah(a)zimbra.com> writes:
yaSSL may be another worthwhile alternative. It does have GPL
licensing
as well.
GPL or LGPL? GPL is really bad from a distribution standpoint (even worse
than OpenSSL's licensing, by a long shot). GnuTLS was LGPL, which was why
it was an attractive choice.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
10:21 p.m.
--On Friday, February 22, 2008 6:08 PM -0800 Russ Allbery
<rra(a)stanford.edu> wrote:
Quanah Gibson-Mount <quanah(a)zimbra.com> writes:
> yaSSL may be another worthwhile alternative. It does have GPL licensing
> as well.
GPL or LGPL? GPL is really bad from a distribution standpoint (even worse
than OpenSSL's licensing, by a long shot). GnuTLS was LGPL, which was why
it was an attractive choice.
GPL, but you can also release it under other licenses in various
circumstances.
<http://www.yassl.com/flossException.html>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
5458
days inactive
5465
days old
13 comments
7 participants
participants (7)
-
Albert Chin -
Andrew Bartlett -
Gavin Henry -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Russ Allbery