Bug#541256: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1
Vedran Furač
Version: 2.4.17-1
Severity: important
OpenLDAP+gnutls worked fine for me for more than a year, but now I have
TLS problems again. It started on my unstable client when libnss-ldap
reported:
TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1
Then I upgraded gnutls and ldap on my server from lenny to unstable and
now even slapd doesn't start:
TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1.
main: TLS init def ctx failed: -1
If I comment out line which defines cipher:
TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1
it works again.
$ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1
TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0
...so I don't see why it shouldn't work.
Thanks, bye!
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (990, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages slapd depends on:
ii adduser 3.110 add and remove users and groups
ii coreutils 6.10-6 The GNU core utilities
ii debconf [debconf-2.0] 1.5.24 Debian configuration
management sy
ii libc6 2.9-23 GNU C Library: Shared libraries
ii libdb4.7 4.7.25-7 Berkeley v4.7 Database
Libraries [
ii libgnutls26 2.6.6-1 the GNU TLS library -
runtime libr
ii libldap-2.4-2 2.4.17-1 OpenLDAP libraries
ii libltdl7 2.2.6a-4 A system independent dlopen
wrappe
ii libperl5.10 5.10.0-19 Shared Perl library
ii libsasl2-2 2.1.23.dfsg1-1 Cyrus SASL - authentication
abstra
ii libslp1 1.2.1-7.5 OpenSLP libraries
ii libwrap0 7.6.q-16 Wietse Venema's TCP
wrappers libra
ii perl [libmime-base64-perl 5.10.0-19 Larry Wall's Practical
Extraction
ii psmisc 22.6-1 Utilities that use the proc
filesy
ii unixodbc 2.2.11-16 ODBC tools libraries
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.23.dfsg1-1 Cyrus SASL - pluggable
authenticat
Versions of packages slapd suggests:
ii ldap-utils 2.4.17-1 OpenLDAP utilities
-- debconf information:
* slapd/tlsciphersuite:
slapd/fix_directory: true
shared/organization: nodomain
slapd/upgrade_slapcat_failure:
slapd/backend: BDB
slapd/allow_ldap_v2: false
slapd/no_configuration: false
slapd/move_old_database: true
slapd/suffix_change: false
slapd/slave_databases_require_updateref:
slapd/dump_database_destdir: /var/backups/slapd-VERSION
slapd/autoconf_modules: true
slapd/domain: nodomain
slapd/password_mismatch:
slapd/invalid_config: true
slapd/slurpd_obsolete:
slapd/upgrade_slapadd_failure:
slapd/dump_database: when needed
slapd/migrate_ldbm_to_bdb: false
slapd/purge_database: false
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Quanah Gibson-Mount
<ved...@vedranf.mine.nu> wrote:
> Package: slapd
> Version: 2.4.17-1
> Severity: important
>
> OpenLDAP+gnutls worked fine for me for more than a year, but now I have
> TLS problems again. It started on my unstable client when libnss-ldap
> reported:
>
> TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1
>
> Then I upgraded gnutls and ldap on my server from lenny to unstable and
> now even slapd doesn't start:
>
> TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1.
> main: TLS init def ctx failed: -1
>
> If I comment out line which defines cipher:
>
> TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1
>
> it works again.
>
> $ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1
> TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0
>
> ...so I don't see why it shouldn't work.
>
> Thanks, bye!
Filed upstream:
<http://www.openldap.org/its/index.cgi/?findid=6251>
Note that a difference for GnuTLS with 2.4.17 is that it uses gcrypt if a
newer GnuTLS is detected, so it is possible gcrypt is broken.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount
<qua...@zimbra.com> wrote:
>> Thanks, bye!
>
>
> Filed upstream:
>
> <http://www.openldap.org/its/index.cgi/?findid=6251>
>
> Note that a difference for GnuTLS with 2.4.17 is that it uses gcrypt if a
> newer GnuTLS is detected, so it is possible gcrypt is broken.
Please see the upstream comments. The issue is broken behavior on GnuTLS'
part.
Vedran Furač
> --On Wednesday, August 12, 2009 12:22 PM -0700 Quanah Gibson-Mount
> <qua...@zimbra.com> wrote:
>
>>> Thanks, bye!
>>
>> Filed upstream:
>>
>> <http://www.openldap.org/its/index.cgi/?findid=6251>
>>
>> Note that a difference for GnuTLS with 2.4.17 is that it uses gcrypt if a
>> newer GnuTLS is detected, so it is possible gcrypt is broken.
>
> Please see the upstream comments. The issue is broken behavior on GnuTLS'
> part.
Ah... I see. Thanks for forwarding it! Anyway, I tried his suggestion
and changed slapd.conf on server side and libnss/pam_ldap.conf/ldap.conf
on client to have:
TLSCipherSuite +AES-256-CBC:+SHA1
Now slapd starts, but connection (e.g. getent passwd) to it fails with:
TLS: can't connect: No supported cipher suites have been found..
And ldapsearch -ZZ:
TLS: can't connect: A TLS packet with unexpected length was received.
Regards!
Quanah Gibson-Mount
<ved...@vedranf.mine.nu> wrote:
>> Please see the upstream comments. The issue is broken behavior on
>> GnuTLS' part.
>
> Ah... I see. Thanks for forwarding it! Anyway, I tried his suggestion
> and changed slapd.conf on server side and libnss/pam_ldap.conf/ldap.conf
> on client to have:
>
> TLSCipherSuite +AES-256-CBC:+SHA1
>
> Now slapd starts, but connection (e.g. getent passwd) to it fails with:
>
> TLS: can't connect: No supported cipher suites have been found..
>
> And ldapsearch -ZZ:
>
> TLS: can't connect: A TLS packet with unexpected length was received.
Sadly, this is likely yet another case of broken behavior on GnuTLS' part,
of which there are growing numbers, like
<http://www.openldap.org/its/index.cgi/?findid=6252>. I'd recommend
building your own openldap server and clients using OpenSSL, which is known
to actually work.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount
<qua...@zimbra.com> wrote:
> --On Thursday, August 13, 2009 2:12 AM +0200 Vedran Furač
> <ved...@vedranf.mine.nu> wrote:
>
>
>>> Please see the upstream comments. The issue is broken behavior on
>>> GnuTLS' part.
>>
>> Ah... I see. Thanks for forwarding it! Anyway, I tried his suggestion
>> and changed slapd.conf on server side and libnss/pam_ldap.conf/ldap.conf
>> on client to have:
>>
>> TLSCipherSuite +AES-256-CBC:+SHA1
Try:
TLSCipherSuite +RSA:+AES-256-CBC:+SHA1
Vedran Furač
> Try:
>
> TLSCipherSuite +RSA:+AES-256-CBC:+SHA1
It works! Thank you both.
I would usually close this report, but it might be useful having it here
for others as they could encounter the same problem, especially because
searching for "+RSA:+AES-256-CBC:+SHA1" on google didn't get any result.
You decide what is the best.
Regards!
Steve Langasek
thanks
On Wed, Aug 12, 2009 at 02:49:05PM -0700, Quanah Gibson-Mount wrote:
> >Note that a difference for GnuTLS with 2.4.17 is that it uses gcrypt if a
> >newer GnuTLS is detected, so it is possible gcrypt is broken.
> Please see the upstream comments. The issue is broken behavior on
> GnuTLS' part.
This appears to be caused by our switch to using GnuTLS's cipher suite
parsing functions in 2.4.14 (due to ITS#5887). The syntax that GnuTLS
uses is quite different from what we were using in 2.4.13 and earlier.
A change in behavior because OpenLDAP has switched to using a different
parser for cipher suites than what was in place previously isn't "broken
behavior on GnuTLS' part". Your continuous maligning of GnuTLS in Debian
bug reports is unhelpful; we cannot ship libldap linked against OpenSSL for
license reasons, so reminding us how much you disapprove of GnuTLS isn't
going to change anything - aside from discouraging me from spending time on
bug mail for the openldap package.
If the current parser behavior is going to remain in place (which is not yet
clear), then we should address this in the packaging on upgrade, either by
converting the TLSCipherSuite values automatically or at minimum by
notifying the user that an adjustment will be needed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Howard Chu
> parser for cipher suites than what was in place previously isn't "broken
> behavior on GnuTLS' part".
Steve: the fact that the behavior changed isn't "broken"; the fact that the
behavior is so completely different from the official GnuTLS documentation *is*.
> Your continuous maligning of GnuTLS in Debian
> bug reports is unhelpful; we cannot ship libldap linked against OpenSSL for
> license reasons, so reminding us how much you disapprove of GnuTLS isn't
> going to change anything - aside from discouraging me from spending time on
> bug mail for the openldap package.
As software and security professionals, we cannot in good conscience stand
mute on the subject. The quality of the code in GnuTLS is obviously low, the
risk of security vulnerabilities is high, and the cost in maintenance is only
going up. Whether you want to hear it or not, we are obligated to state for
the record that using GnuTLS is a bad idea, because that's the objective truth.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/