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.
<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.
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 hyc@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.
On Sat, 2008-02-16 at 14:44 -0800, Russ Allbery wrote:
Howard Chu hyc@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 abartlet@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 wrote:
Andrew Bartlettabartlet@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 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.
Howard Chu hyc@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.
--On Thursday, February 21, 2008 12:06 AM -0800 Howard Chu hyc@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
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.
--On Thursday, February 21, 2008 7:16 PM -0600 Albert Chin openldap-devel@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
Quanah Gibson-Mount quanah@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.
--On Friday, February 22, 2008 6:08 PM -0800 Russ Allbery rra@stanford.edu wrote:
Quanah Gibson-Mount quanah@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
-
Albert Chin -
Andrew Bartlett -
Gavin Henry -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Russ Allbery