Your message dated Wed, 11 Jun 2014 16:02:30 -0700
with message-id
<camxh3qdz17ljs5xe8w_ca-vxyyqq1ewabnot7-koylrkwsg...@mail.gmail.com>
and subject line gnutls certificate reading performance fixed upstream
has caused the Debian Bug report #351897,
regarding libnss-ldap and pam-ldap extreemly slow if ca-certicates installed
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
351897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351897
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libnss-ldap
Version: 238-1.1
libnss-ldap hits a severe performance penalty when the cacertdir
parameter points to a directory with a large number of certificate
files. The slow down is a factor 80 after installing package
ca-certificates! It is primarily related to the number of files. If
using only one single file containg all certificates there is no
noticable slowdown.
How to reproduce:
* Install and configure slapd, libnss-ldap.conf, nsswitch.conf
to use TLS. Check that all is working.
* Change libnss-ldap.conf:
tls_cacertdir /etc/ssl/certs
ssl start_tls
* getent passwd
Should be reasonable quick
* aptitude install ca-certificates
* getent passwd
Will be about 80 times slower now! And we are now taking about 20
seconds.
If the nscd is running then the penalty will only be noticed once after
each nscd restart or each time an enumeration is done like "getent passwd".
A workaround to avoid risking this performance penalty is to create a
separate directory and place only the few
certificates needed there, possibly also in just one single file:
tls_cacertdir /etc/ssl/libnssldap-certs
But specifying just a cacertfile may not enough since the cacertdir
parameter may be set in ldap.conf,
as described next.
libnns-ldap does not only use its own config file libnss-ldap.conf but
ldap.conf. So when I removed the parameter tls_cacertdir from
libnss-ldap.conf it still was set from ldap.conf which took me some time to
understand why this didnt solve my performance problems.
But yet another caveat regarding the cofiguration is that if neither of
ssl start_tls
ssl on
is specified in the config then the the tls_cacertdir setting will not
have any effect at all and instead get its value
from ldap.conf!!! This means that this configuration:
uri http://127.0.0.1 https://some-host/
will hit severe perormance penalty for the https host. Do not know if
anyone uses such a configuration, but it is obviosuly possible!
Experiments shows that the performance degradation has to do with the number
of files in the directory. Not the number of certs. Using only one file
with all certs does
not slow down nearly as much.
A fix for this problem would be to have libnss/pam-ldap to:
* Not read in any certificates at startup
* Only read a cert based on its <hash>.0 when needed, just as
ldapsearch et.al does.
* Not use the ldap.conf parameters
/Petter
--- End Message ---
--- Begin Message ---
This appears to be the same bug as #400448. The blog post linked from
there is informative, but the short version is that the performance of
gnutls_certificate_set_x509_trust_file was improved a lot in 2.3.3, so
etch and later.
Meanwhile, the patch from #205609 was dropped when switching to the
upstream GnuTLS support in OpenLDAP 2.4, where the TLS_CACERTDIR
option is not supported when built against GnuTLS.
Now in Debian (since 2.4.24-1) the default ldap.conf includes:
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
and I'm not aware of any performance problems with that.
thanks,
Ryan
--- End Message ---
