Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
A patch has been committed to the package svn tree to fix handling of cipher lists, which leaves this issue: On Tue, Jan 29, 2008 at 11:09:32AM -0800, Steve Langasek wrote: I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. I had a poke around http://www.openssl.org/docs/apps/ciphers.html, which lists all the various keywords recognized by OpenSSL. Mapping these onto the known GnuTLS ciphers using 'openssl ciphers -v' and 'gnutls-cli -l', here's what I get: MEDIUM - TLS_ANON_DH_ARCFOUR_MD5:TLS_RSA_ARCFOUR_SHA1:TLS_RSA_ARCFOUR_MD5 HIGH - TLS_ANON_DH_AES_256_CBC_SHA1:TLS_DHE_RSA_AES_256_CBC_SHA1:TLS_DHE_DSS_AES_256_CBC_SHA1:TLS_RSA_AES_256_CBC_SHA1:TLS_ANON_DH_AES_128_CBC_SHA1:TLS_DHE_RSA_AES_128_CBC_SHA1:TLS_DHE_DSS_AES_128_CBC_SHA1:TLS_RSA_AES_128_CBC_SHA1:TLS_ANON_DH_3DES_EDE_CBC_SHA1:TLS_DHE_RSA_3DES_EDE_CBC_SHA1:TLS_DHE_DSS_3DES_EDE_CBC_SHA1:TLS_RSA_3DES_EDE_CBC_SHA1 LOW - empty list DEFAULT: MED+HIGH, w/o ANON_DH, w/ TLS_RSA_EXPORT_ARCFOUR_40_MD5 EXP,EXPORT,EXPORT40 - TLS_RSA_EXPORT_ARCFOUR_40_MD5 eNULL,NULL - TLS_RSA_NULL_MD5 aNULL - TLS_ANON_DH_AES_256_CBC_SHA1:TLS_ANON_DH_AES_128_CBC_SHA1:TLS_ANON_DH_3DES_EDE_CBC_SHA1:TLS_ANON_DH_ARCFOUR_MD5 SSLv2 - empty list But this is only a partial list of the most relevant aliases; there are also aliases for each authentication, key exchange, and encryption algorithm, and OpenSSL supports various forms of negation and sorting that aren't supported here by GnuTLS. I'm pretty sure I don't want to implement support for migrating the full set of OpenSSL cipher specs in shell. :P Do you think converting the above aliases would be good enough coverage? Or do we need to provide some upgrade handling for all the possibilities, and therefore we're doomed to add yet another debconf error message here? In the latter case I'm probably not going to spend the effort on auto-migrating any of the values. -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
On Sat, Jan 26, 2008 at 12:33:28PM +0100, T.A. van Roermund wrote: # all cipher suites as currently supported by gnutls, # constructed using command: # gnutls-cli -l | grep -E ^TLS | cut -d\ -f1 | xargs echo TLSCipherSuite TLS_ANON_DH_ARCFOUR_MD5 TLS_ANON_DH_3DES_EDE_CBC_SHA1 TLS_ANON_DH_AES_128_CBC_SHA1 TLS_ANON_DH_AES_256_CBC_SHA1 TLS_PSK_SHA_ARCFOUR_SHA1 TLS_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_PSK_SHA_AES_128_CBC_SHA1 TLS_PSK_SHA_AES_256_CBC_SHA1 TLS_DHE_PSK_SHA_ARCFOUR_SHA1 TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_DHE_PSK_SHA_AES_128_CBC_SHA1 TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_AES_128_CBC_SHA1 TLS_SRP_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_DSS_AES_128_CBC_SHA1 TLS_SRP_SHA_RSA_AES_128_CBC_SHA1 TLS_SRP_SHA_DSS_AES_256_CBC_SHA1 TLS_SRP_SHA_RSA_AES_256_CBC_SHA1 TLS_DHE_DSS_ARCFOUR_SHA1 TLS_DHE_DSS_3DES_EDE_CBC_SHA1 TLS_DHE_DSS_AES_128_CBC_SHA1 TLS_DHE_DSS_AES_256_CBC_SHA1 TLS_DHE_RSA_3DES_EDE_CBC_SHA1 TLS_DHE_RSA_AES_128_CBC_SHA1 TLS_DHE_RSA_AES_256_CBC_SHA1 TLS_RSA_NULL_MD5 TLS_RSA_EXPORT_ARCFOUR_40_MD5 TLS_RSA_ARCFOUR_SHA1 TLS_RSA_ARCFOUR_MD5 TLS_RSA_3DES_EDE_CBC_SHA1 TLS_RSA_AES_128_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 Before, using OpenSSL, everything worked perfectly. Now, LDAPS is completely broken. Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). I see that if I leave the cipher list blank, gnutls-cli negotiates TLS_RSA_AES_256_CBC_SHA; so if I set TLSCipherSuite TLS_RSA_AES_256_CBC_SHA, it works just fine. The full list of ciphers that gnutls clients appear to negotiate by default is: TLS_DHE_RSA_AES_256_CBC_SHA, TLS_DHE_RSA_AES_128_CBC_SHA, TLS_DHE_RSA_3DES_EDE_CBC_SHA, TLS_DHE_DSS_AES_256_CBC_SHA, TLS_DHE_DSS_AES_128_CBC_SHA, TLS_DHE_DSS_3DES_EDE_CBC_SHA, TLS_DHE_DSS_RC4_128_SHA, TLS_RSA_AES_256_CBC_SHA, TLS_RSA_AES_128_CBC_SHA, TLS_RSA_3DES_EDE_CBC_SHA, TLS_RSA_RC4_128_SHA, TLS_RSA_RC4_128_MD5 So if you don't want to use the default cipher settings, you can perhaps choose one of these ciphers individually that meets your needs. The fact that ldap_pvt_tls_set_option() hangs indefinitely when given a list of more than one cipher is certainly a bug which should be fixed. I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
Steve Langasek wrote: Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. If I leave it blank, it still doesn't work. The behaviour is then exactly equal to the current situation. Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). I can confirm that, the reason why I left out the : is this hang. I thought that maybe gnutls parses the string differently and needs spaces in between, that's why I replaced those characters with spaces. Anyway, do you file a bug report for this hang? I see that if I leave the cipher list blank, gnutls-cli negotiates TLS_RSA_AES_256_CBC_SHA; so if I set TLSCipherSuite TLS_RSA_AES_256_CBC_SHA, it works just fine. How exactly do you find out? Then I might try the same on my PC. The full list of ciphers that gnutls clients appear to negotiate by default is: TLS_DHE_RSA_AES_256_CBC_SHA, TLS_DHE_RSA_AES_128_CBC_SHA, TLS_DHE_RSA_3DES_EDE_CBC_SHA, TLS_DHE_DSS_AES_256_CBC_SHA, TLS_DHE_DSS_AES_128_CBC_SHA, TLS_DHE_DSS_3DES_EDE_CBC_SHA, TLS_DHE_DSS_RC4_128_SHA, TLS_RSA_AES_256_CBC_SHA, TLS_RSA_AES_128_CBC_SHA, TLS_RSA_3DES_EDE_CBC_SHA, TLS_RSA_RC4_128_SHA, TLS_RSA_RC4_128_MD5 So if you don't want to use the default cipher settings, you can perhaps choose one of these ciphers individually that meets your needs. None of thise ciphers seems to work (at least in combination with Thunderbird). I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. That might be a good idea. Best regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: Have you verified that port 636 is open? I.e., telnet localhost 636 The port is open: $ telnet localhost 636 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. And: $ netstat --listening --numeric --program | grep slapd tcp0 0 127.0.0.1:389 0.0.0.0:* LISTEN 23763/slapd tcp0 0 0.0.0.0:636 0.0.0.0:* LISTEN 23763/slapd (And ldapsearch is still unable to connect.) Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
--On Saturday, January 26, 2008 12:33 PM +0100 T.A. van Roermund [EMAIL PROTECTED] wrote: Quanah Gibson-Mount wrote: Have you verified whether or not you can connect using LDAPS via the command line tools? (ldapsearch, ldapwhoami, etc). Yes I did: $ ldapsearch -H ldaps://localhost:636/ -X cn=admin ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Have you verified that port 636 is open? I.e., telnet localhost 636 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
