[Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem

[Steve Langasek]

On Tue, Jan 29, 2008 at 08:27:03PM +0100, T.A. van Roermund wrote:
> 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.

Ok.  Does your certificate have a proper cn, matching the fqdn of your
server?  That's the only other case where I can reproduce the described
behavior, but I don't know if that's a behavior change relative to the
OpenSSL version.  (I would have hoped that OpenSSL would also refuse to
negotiate SSL/TLS with a server whose cn doesn't match the hostname being
connected to, since this subverts the SSL security model.)

> > 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.

Running as root on the client:

# tcpdump -i eth1 -n host borges and '(port ldap or port ldaps)' \
    -s 1500 -w ~vorlon/ldaps.pcap

then attempt to connect to the server from the client, ctrl-C out of
tcpdump, and analyze the resulting packet capture with wireshark -r
ldaps.pcap (as a non-root user).

If you're testing with localhost, then you'll want to do, e.g.,

# tcpdump -i lo -n port ldap or port ldaps -s 1500 -w ldaps.pcap

> > 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).

If you're seeing this behavior even when TLSCipherSuite is left blank, then
I think your failure is different than the cipher negotiation problem, and I
suspect the cn problem above, or a problem with a lack of a CA configured on
the client side.

-- 
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/
slangasek at ubuntu.com                                     vorlon at debian.org