[Pkg-openldap-devel] Potential bug with OpenSSL certificates and GnuTLS+OpenLDAP packaging in Wheezy

Sat Dec 21 14:33:23 UTC 2013

Hello!

I've been stuck debugging OpenLDAP + GnuTLS and OpenSSL certificates (I
really didn't want to rewrite my certificate generation) as suggested by
the wiki here: https://wiki.debian.org/LDAP/OpenLDAPSetup (at symptoms
round 2).
It turns out that clients try to connect to OpenLDAP (both openssl and
gnutls clients) using TLS1.2 which judging by this output, the server does
not support properly:
# gnutls-cli-debug ldap -p 636
Resolving 'ldap'...
Connecting to '10.146.12.158:636'...
Checking for SSL 3.0 support... yes
Checking whether %COMPAT is required... no
Checking for TLS 1.0 support... yes
Checking for TLS 1.1 support... yes
Checking fallback from TLS 1.1 to... N/A
Checking for TLS 1.2 support... no
Checking whether we need to disable TLS 1.0... N/A
Checking for Safe renegotiation support... yes
Checking for Safe renegotiation support (SCSV)... yes
Checking for HTTPS server name... not checked
Checking for version rollback bug in RSA PMS... no
Checking for version rollback bug in Client Hello... no
Checking whether the server ignores the RSA PMS version... no
Checking whether the server can accept Hello Extensions... yes
Checking whether the server can accept cipher suites not in SSL 3.0 spec...
yes
Checking whether the server can accept a bogus TLS record version in the
client hello... yes
Checking for certificate information... N/A
Checking for trusted CAs... N/A
Checking whether the server understands TLS closure alerts... yes
Checking whether the server supports session resumption... no
Checking for export-grade ciphersuite support... no
Checking RSA-export ciphersuite info... N/A
Checking for anonymous authentication support... no
Checking anonymous Diffie-Hellman group info... N/A
Checking for ephemeral Diffie-Hellman support... no
Checking ephemeral Diffie-Hellman group info... N/A
Checking for AES cipher support (TLS extension)... yes
Checking for CAMELLIA cipher support (TLS extension)... yes
Checking for 3DES cipher support... yes
Checking for ARCFOUR 128 cipher support... yes
Checking for ARCFOUR 40 cipher support... no
Checking for MD5 MAC support... yes
Checking for SHA1 MAC support... yes
Checking for max record size (TLS extension)... yes
Checking for OpenPGP authentication support (TLS extension)... no

Clients still try to connect with TLS1.2 to the server, but you get this
error message when you try:
# gnutls-cli -d 4 -p 636 ldap
Resolving 'ldap'...
Connecting to '10.146.12.158:636'...
|<4>| REC[0xe39500]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:695
|<4>| REC[0xe39500]: Allocating epoch #1
|<3>| HSK[0xe39500]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<2>| EXT[0xe39500]: Sending extension SERVER NAME (20 bytes)
|<2>| EXT[0xe39500]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| EXT[0xe39500]: Sending extension SESSION TICKET (0 bytes)
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
|<2>| EXT[0xe39500]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0xe39500]: CLIENT HELLO was sent [94 bytes]
|<4>| REC[0xe39500]: Sending Packet[0] Handshake(22) with length: 94
|<4>| REC[0xe39500]: Sent Packet[1] Handshake(22) with length: 99
|<2>| ASSERT: gnutls_buffers.c:640
|<2>| ASSERT: gnutls_record.c:969
|<2>| ASSERT: gnutls_handshake.c:2762
*** Fatal error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[0xe39500]: Sending Packet[1] Alert(21) with length: 2
|<4>| REC[0xe39500]: Sent Packet[2] Alert(21) with length: 7
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.
|<4>| REC[0xe39500]: Epoch #0 freed
|<4>| REC[0xe39500]: Epoch #1 freed

I might also add that the TLSCipherSuite directive documentation is
horrible. I spent well over an hour trying to find a cipher suite string
that worked at all (setting an invalid one in cn=config crashes the server).
I found some correspondence here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256
That helped me find a cipher suite string that actually made my clients
able to connect at all: "+RSA:+AES-256-CBC:+SHA1:-VERS-TLS1.2". This is the
minimal string that makes both openssl and gnutls clients able to connect
without specifying a cipher list themselves.
I've tried using more general olcTLSCipherSuite definitions, including only
"-VERS-TLS1.2", but it seems that it does nothing and definitions
like: "+KX-ALL:+CIPHER-ALL:+MAC-ALL:-VERS-TLS1.2" seems to break the server
like any unsupported string would.
http://gnutls.org/manual/html_node/Priority-Strings.html has helped me
some, but I haven't managed to use it to build a more general
TLSCipherSuite string that wouldn't just be listing all of them, but you
can't do that either, because you get an error like this:
ldap_modify: Invalid syntax (21)
        additional info: olcTLSCipherSuite: value #0 invalid per syntax

This a snippet from the handshake output from a successful connect using
gnutls-cli:
|<2>| EXT[0x1ab7500]: Sending extension SERVER NAME (20 bytes)
|<2>| EXT[0x1ab7500]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| EXT[0x1ab7500]: Sending extension SESSION TICKET (0 bytes)
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
|<2>| EXT[0x1ab7500]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0x1ab7500]: CLIENT HELLO was sent [140 bytes]
|<4>| REC[0x1ab7500]: Sending Packet[0] Handshake(22) with length: 140
|<4>| REC[0x1ab7500]: Sent Packet[1] Handshake(22) with length: 145
|<4>| REC[0x1ab7500]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x1ab7500]: Received Packet[0] Handshake(22) with length: 81
|<4>| REC[0x1ab7500]: Decrypted Packet[0] Handshake(22) with length: 81
|<3>| HSK[0x1ab7500]: SERVER HELLO was received [81 bytes]
|<3>| HSK[0x1ab7500]: Server's version: 3.2
|<3>| HSK[0x1ab7500]: SessionID length: 32
|<3>| HSK[0x1ab7500]: SessionID:
256659f9e27a593ca972a30157531673468d82f1cb65532121b503c09cfb6944
|<3>| HSK[0x1ab7500]: Selected cipher suite: RSA_AES_256_CBC_SHA1
|<2>| EXT[0x1ab7500]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| HSK[0x1ab7500]: Safe renegotiation succeeded
|<4>| REC[0x1ab7500]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[0x1ab7500]: Received Packet[1] Handshake(22) with length: 6614
|<4>| REC[0x1ab7500]: Decrypted Packet[1] Handshake(22) with length: 6614
|<3>| HSK[0x1ab7500]: CERTIFICATE was received [6614 bytes]

It seems to be expecting handshake packets with a size of 1 byte, but maybe
that isn't a blocking violation in TLS1.1 and earlier?
Well, I feel like I'm out of my depth here in any case and I'm hoping that
you might at the very least be able to point me in the right direction of
where to file an issue for this since I'm not sure if it is related to
GnuTLS, OpenSSL, OpenLDAP, or the packaging of OpenLDAP+GnuTLS.

Best regards,
Mikael Knutsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20131221/a4c5e92a/attachment-0001.html>