Steinar H. Gunderson wrote:
>> With libnss-ldap 238-1.2 installed
>>
>> $ cat /proc/sys/kernel/random/entropy_avail; \
>> getent passwd user_in_ldap; \
>> cat /proc/sys/kernel/random/entropy_avail
>> 3585
>> passwd entry here
>> 129
>
> Are you sure it's not falling back to non-TLS here? Or local files somehow? I
> can't see a reason why it would fail any better than 251, given that a
> failure is still a failure and the relevant change is what it does after the
> fact...
I'm rather certain it's not falling back to non-TLS. There are NO
configuration file changes when I switch back and forth between versions
238 and 251.
My /etc/ldap/ldap.conf files on various hosts all contain
==========
TLS_CIPHER_SUITE HIGH:!ADH
TLS_CACERT /etc/ssl/certs/my_CA_cert.pem
TLS_REQCERT demand
TLS_CRLCHECK none
==========
And according to the manual page
TLS_REQCERT <level>
demand | hard
These keywords are equivalent.
The server certificate is requested. If no
certificate is provided, or a bad certificate is provided,
the session is immediately terminated.
This is the default setting.
And then in my /etc/ldap/slapd.conf I have the lines
==========
TLSCipherSuite HIGH:!ADH
TLSCACertificateFile /etc/ssl/certs/my_CA_cert.pem
TLSCertificateFile /etc/ssl/certs/ldap.my_domain.pem
TLSCertificateKeyFile /etc/ldap/private/ldap.my_domain.pem
TLSCRLCheck none
TLSVerifyClient never
security ssf=128
==========
According to the manual page, "security ssf=128"
"specifies the overall security strength factor" as being at least 128 bit
encryption for all operations.
I have had these configuration settings in place for at least a year in
order to explicitly prevent non-TLS operation of both the clients and the
server.
I have also verified TLS operation with my currently installed (and
working) libnss-ldap version 238 by capturing loopback traffic with
wireshark/ethereal and performing multiple back-to-back "getent passwd"
commands which (as documented previously) exercises libnss-ldap and slapd
and drain the entropy pool. The only non-encrypted LDAP traffic in the
captures is when certificates information is being exchanged as part of the
STARTTLS and I can see the strings from my CA info going back and forth.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
