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/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
