Re: [openssl.org #1292] SSL_add_dir_cert_subjects_to_stack does not check for read access of file, breaking TLS enabled LDAP clients
[EMAIL PROTECTED] via RT wrote: Hi, initial report at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185080 Imho it's more a OpenSSL than a OpenLDAP client problem. The use of TLS_CACERTDIR / TLSCACertificatePath is discouraged in all of the OpenLDAP documentation. See slapd.conf(5), ldap.conf(5) man pages, and the OpenLDAP Admin Guide section 12.2: http://www.openldap.org/doc/admin23/tls.html Regards, Peter Description of problem: During tracking down, why a LDAP enabled postfix cannot lookup via TLS enabled LDAP client I found that openssl function SSL_add_dir_cert_subjects_to_stack is very optimistic relating to the files found in a specified directory. Version-Release number of selected component (if applicable): openssl-0.9.7a-43.4 also openssl-0.9.7.i (latest 0.9.7 release) also openssl-0.9.8.a (latest 0.9.8 release) in conjunction with openldap-2.2.13-4 also openldap-2.2.30 (latest 2.2 release) also openldap-2.3.20 (latest 2.3 release) How reproducible: Always Steps to Reproduce: 1. Create a directory for local PKI storage, e.g. /etc/pki 2. Store local CA, local server certificates and local keys into this directory 3. Set proper permissions to keys, e.g. chmod o-rwx *.key.pem # ll /etc/pki/ total 120 lrwxrwxrwx 1 root root 23 Sep 14 15:42 592fcc04.0 -> ca.crt -r--r--r-- 1 root root 1834 Sep 14 15:39 ca.crt -r--r--r-- 1 root root 2529 Sep 14 15:39 AE-CA-Class4-2005-A.crt -r 1 root root 5875 Sep 14 15:45 ca+cert+key.pem -r--r--r-- 1 root root 4196 Sep 14 16:07 ca+cert.pem -r--r--r-- 1 root root 2362 Sep 14 15:37 cert.crt -r--r- 1 root root 4041 Sep 14 15:50 cert+key.pem -r--r- 1 root ldap 1679 Sep 14 15:37 key.pem (note: group=ldap for LDAP server, which reads key file for server TLS after changing the user to "ldap") 4. Configure /etc/openldap/slapd.conf for TLS like TLSCACertificateFile/etc/pki/ca.crt TLSCACertificatePath/etc/pki TLSCertificateFile /etc/pki/crt.crt TLSCertificateKeyFile /etc/pki/key.pem 5. Configure /etc/openldap/ldap.conf related URI ldaps://ldapserver/ #URIldap://ldapserver/ BASE dc=example,dc=com TLS_CACERTDIR /etc/pki# <- important! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1292] SSL_add_dir_cert_subjects_to_stack does not check for read access of file, breaking TLS enabled LDAP clients
Hi,
initial report at:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185080
Imho it's more a OpenSSL than a OpenLDAP client problem.
Regards,
Peter
Description of problem:
During tracking down, why a LDAP enabled postfix cannot lookup via TLS
enabled
LDAP client I found that openssl function SSL_add_dir_cert_subjects_to_stack
is
very optimistic relating to the files found in a specified directory.
Version-Release number of selected component (if applicable):
openssl-0.9.7a-43.4
also openssl-0.9.7.i (latest 0.9.7 release)
also openssl-0.9.8.a (latest 0.9.8 release)
in conjunction with
openldap-2.2.13-4
also openldap-2.2.30 (latest 2.2 release)
also openldap-2.3.20 (latest 2.3 release)
How reproducible:
Always
Steps to Reproduce:
1. Create a directory for local PKI storage, e.g.
/etc/pki
2. Store local CA, local server certificates and local keys into this
directory
3. Set proper permissions to keys, e.g.
chmod o-rwx *.key.pem
# ll /etc/pki/
total 120
lrwxrwxrwx 1 root root 23 Sep 14 15:42 592fcc04.0 -> ca.crt
-r--r--r-- 1 root root 1834 Sep 14 15:39 ca.crt
-r--r--r-- 1 root root 2529 Sep 14 15:39 AE-CA-Class4-2005-A.crt
-r 1 root root 5875 Sep 14 15:45 ca+cert+key.pem
-r--r--r-- 1 root root 4196 Sep 14 16:07 ca+cert.pem
-r--r--r-- 1 root root 2362 Sep 14 15:37 cert.crt
-r--r- 1 root root 4041 Sep 14 15:50 cert+key.pem
-r--r- 1 root ldap 1679 Sep 14 15:37 key.pem (note: group=ldap for LDAP
server, which reads key file for server TLS after changing the user to
"ldap")
4. Configure /etc/openldap/slapd.conf for TLS like
TLSCACertificateFile/etc/pki/ca.crt
TLSCACertificatePath/etc/pki
TLSCertificateFile /etc/pki/crt.crt
TLSCertificateKeyFile /etc/pki/key.pem
5. Configure /etc/openldap/ldap.conf related
URI ldaps://ldapserver/
#URIldap://ldapserver/
BASE dc=example,dc=com
TLS_CACERTDIR /etc/pki# <- important!
6. Try ldapsearch usig TLS as root:
ldapsearch -x -H ldaps://ldapserver/
Result: working
7. Try ldapsearch using TLS as normal user:
$ ldapsearch -x -v -H ldaps://ldapserver
Result: not working, message:
ldap_initialize( ldaps://ldapserver )
ldap_bind: Can't contact LDAP server (-1)
Using strace shows me:
open("/etc/pki/key.pem", O_RDONLY) = -1 EACCES (Permission denied)
close(4)= 0
write(2, "ldap_bind: Can\'t contact LDAP server (-1)\n", 42ldap_bind: Can't
contact LDAP server (-1)
) = 42
exit_group(1) = ?
Process 15652 detached
Ooops, why will ldapsearch open this key file??? Ok, thanks to opensource we
are
now now digging through the code:
A) openldap: openldap-2.2.13/libraries/libldap/tls.c
(same code in newer/latest versions)
static STACK_OF(X509_NAME) *
get_ca_list( char * bundle, char * dir )
{
STACK_OF(X509_NAME) *ca_list = NULL;
if ( bundle ) {
ca_list = SSL_load_client_CA_file( bundle );
}
#if defined(HAVE_DIRENT_H) || defined(dirent)
if ( dir ) {
int freeit = 0;
if ( !ca_list ) {
ca_list = sk_X509_NAME_new_null();
freeit = 1;
}
if ( !SSL_add_dir_cert_subjects_to_stack( ca_list, dir ) &&
freeit ) {
sk_X509_NAME_free( ca_list );
ca_list = NULL;
}
}
#endif
return ca_list;
}
Ok, openldap calls an openssl functions to read all certificates in "dir"
and
add to "ca_list".
Note that here is also an opportunity for improvements to be more graceful,
if
SSL_load_client_CA_file works but SSL_add_dir_cert_subjects_to_stack fails.
Currently, the whole ca_list ist dropped.
B) openssl: openssl-0.9.7a/ssl/ssl_cert.c
(same code in newer/latest versions)
/*!
* Add a directory of certs to a stack.
* \param stack the stack to append to.
* \param dir the directory to append from. All files in this directory will
be
* examined as potential certs. Any that are acceptable to
* SSL_add_dir_cert_subjects_to_stack() that are not already in the stack
will be
* included.
* \return 1 for success, 0 for failure. Note that in the case of failure
some
* certs may have been added to \c stack.
*/
#ifndef OPENSSL_SYS_WIN32
#ifndef OPENSSL_SYS_VMS /* This may be fixed in the future */
#ifndef OPENSSL_SYS_MACINTOSH_CLASSIC /* X: Better scheme needed! */
int SSL_add_dir_cert_subjects_to_stack(STACK_OF(X509_NAME) *stack,
const char *dir)
{
DIR *d;
struct dirent *dstruct;
int ret = 0;
CRYPTO_w_lock(CRYPTO_LOCK_READDIR);
d = opendir(dir);
/* Note that a side effect is that the CAs will be sorted by name */
if(!d)
{
SYSerr(SYS_F_OPENDIR, get_last_sys_error());
ERR_add_error_data(3, "opendir('", dir, "')");
Re: .NET wrapper for OpenSSL
I have a sourceforge project pending for creation.On 3/13/06, Kyle Hamilton <[EMAIL PROTECTED]> wrote: This would be a good thing to have available. I don't believe itshould be in the core OpenSSL code, though, but it could be in contrib/ -- I would suggest making it available as a separate projecton sourceforge or somewhere.-Kyle HOn 3/13/06, Frank Laub <[EMAIL PROTECTED]> wrote: > I've just recently put together a C# class library that wraps the crypto DLL> via PInvoke. I was wondering if anyone here would be interested in such a> thing or if perhaps I should just create a seperate project for it. It has > many advantages but the biggest is allowing for ease of use of the OpenSSL> crypto API via managed lanaguages. If anyone is interested, give me a shout.>> -Frank>__ OpenSSL Project http://www.openssl.orgDevelopment Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: .NET wrapper for OpenSSL
I hadn't considered #2. I suppose I could do both in one shot really. Good idea!On 3/13/06, Weijun Max Wang <[EMAIL PROTECTED] > wrote:FrankThis is a very interesting project. IMHO, there are 2 kinds of APIs we can provide:1. A OpenSSL-like one. Original users of OpenSSL may like it.2. Plugin as a service provider for the .NET crypto framework. Existing.NET codes will be easily re-configured to use the OpenSSL implementation. WeijunFrank Laub wrote:> I've just recently put together a C# class library that wraps the crypto> DLL via PInvoke. I was wondering if anyone here would be interested in> such a thing or if perhaps I should just create a seperate project for > it. It has many advantages but the biggest is allowing for ease of use> of the OpenSSL crypto API via managed lanaguages. If anyone is> interested, give me a shout.>> -Frank__ OpenSSL Project http://www.openssl.orgDevelopment Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
ECX extensions.
I looked a bit in detail into the ecpoint format extension stuff. - Currently, as I said yesterday, one cannot compile openssl with OPENSSL_NO_EC. - I am not sure but it seems to me that the tlsext_ecpointformat_list in the SSL is not freed together with an SSL object, so you have a mem leak unless you disable the EC cipher suites. Well, besides that, I have the feeling that the extension code for the point formats is somewhat strange. - The ssl_prepare_client/serverhello_tlsext routines don't serve a real purpose IMO. They are just called before the corresponding ssl_add_client/server... At best, they could be called internally. My goal was to have a small footprint in s3_lib.c There would be some benefit it a prepare routine would ned to be called very early in the process and some heavy work would be avoided, but I don't think this is the case. - The tests in the prepare routine (are EC ciphers proposed) can be done in that add_client_hello_ext, and, if the extension is added, then just the constant octet string is set in the client hello. - It doesn't need to be remembered as such in the SSL object because it is a constant. At most, a flag bit string list for the supported values can be added to the SSL object (not containing the uncompressed) Thus, when receiving the server hello, one would match the bitstring with the received values, and make whatever decision later concerning certificats. - What is the purpose of keeping the pointformat list in a saved session? If a session is renegotiated, shouldn't all these information concerning ciphers go away? A renego could end with a totally different suite. This is not the same situation as with the hostname extension, where it may happen that the hostname changes, e.g. when a Host: directive occurs in the data stream, and this "state" should not be lost. Comments? -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #1291] [PATCH] Remove old libdes support?
Hi, Various places in the source say that old des support is going to be removed before 1.0. I think it's time to move forward. I think we have 2 options: - Completly drop the old des support, including des_old.h - Drop the libdes compatibility, so that it's only compatible with older openssl versions, and people can still use the des_* versions. The second option would be removing the des_old.c, des_old2.c files, and change des_old.h to remove the libdes compatibility. I think the attached patch removes most of it, but maybe more can/should be removed? We could also change des.h to not default to OPENSSL_ENABLE_OLD_DES_SUPPORT. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1290] [PATCH] Convert destest.c to use DES_* functions.
Hi, The attached patch converts destest.c to use DES_* function instead of des_* functions. It's the only part of the source that is still using the old names. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
