Package: libgnutls26
Severity: serious
Version: 2.12.20-8
cacert.org recently started signing certs with sha512WithRSAEncryption
Consider the following scenario:
- some service running on a Debian stable (wheezy) host (e.g. slapd),
admin replaces their cacert certificate with one of these new certs
- clients (e.g. PAM LDAP module, Apache mod_authnz_ldap) on Debian hosts
linked against gnutls
Everything stops working when the replacement certificate is installed
Troubleshooting, the following is observed:
- running ldapsearch or similar commands, the user sees errors like:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
or with "-d 1" for debugging, there is more detail but it doesn't help:
TLS: can't connect: A TLS packet with unexpected length was received..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
- the user then tries openssl s_client
openssl s_client -connect ldap-host.example.org:636 -tls1 -CAfile
/etc/ssl/certs/cacert.org.pem
and it connects successfully
- if the user also tries gnutls-cli however, it does not work, failing
with errors like this:
GnuTLS error: A TLS packet with unexpected length was received.
- then the admin tries putting their server (e.g. slapd) in debug mode
and sees errors like this
Could not negotiate a supported cipher suite
- the fact that openssl s_client worked and gnutls-cli did not work may
leave them feeling it is gnutls problems again (a Google search finds
plenty of old posts complaining about gnutls and suggesting people
should recompile everything with openssl)
- running gnutls-cli in debug mode, I notice the following:
$ gnutls-cli -p 636 --priority NORMAL:+SIGN-RSA-SHA512 -d 255
ldap-host.example.org
|<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
Even explicitly requesting SHA512 doesn't help:
gnutls-cli -p 636 --priority NORMAL:+SIGN-RSA-SHA512 -d 255
ldap-host.example.org
It seems that the gnutls client code in wheezy does not signal support
for the SHA512 stuff in the client hello message even if it is requested
in the cipher suite
$ gnutls-cli --list | grep 512
MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, MAC-NULL
PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256,
SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1,
SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD2
suggests that the RSA-SHA512 is present and should work, but it doesn't
This is likely to be particularly annoying for people to troubleshoot,
especially if they have only allocated 5-10 minutes to replace their
certificate and they end up spending hours digging through their logs
and pulling their hair out before they realize what is wrong
Looking at the connections with tcpdump, I notice:
- client sends SSL client hello
- server drops connection without sending more data back to client
A suggested workaround is for the admin to create their own local root
CA instead of relying on CA cert. That means that the admin can ensure
that any changes to CA policy (e.g. using SHA512) are tested before
being forced on people.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
