Full_Name: Gabriel Gritsch Version: 2.4.39 OS: Mac OS X 10.9.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.234.244.166) Hi all, would it be possible to support Apples "Common Crypto Services" instead of OpenSSL because the OpenSSL-functions are marked as deprecated since OS X 10.7 and produce a lot of warnings. best regards Gabriel
gabriel@gritsch-soft.com wrote: > Full_Name: Gabriel Gritsch > Version: 2.4.39 > OS: Mac OS X 10.9.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.234.244.166) > > > Hi all, > > would it be possible to support Apples "Common Crypto Services" instead of > OpenSSL because the OpenSSL-functions are marked as deprecated since OS X 10.7 > and produce a lot of warnings. If someone submits a patch for this we will of course review and consider it. But in general, it sounds like a bad idea. In light of Apple's now-infamous "goto fail" bug http://www.zdnet.com/apples-goto-fail-tells-us-nothing-good-about-cupertinos-software-delivery-process-7000027449/ it would be poor practice to migrate away from a security package that is now receiving broad and in-depth scrutiny, to one that only has Apple's assurances behind it. Also given Apple's success rate with security in general http://online.wsj.com/articles/apple-celebrity-accounts-compromised-by-very-targeted-attack-1409683803 it seems like a poor choice. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
patch welcome, but not recommended
changed notes changed state Open to Feedback moved from Incoming to Software Enhancements
hyc@symas.com wrote: > gabriel@gritsch-soft.com wrote: >> would it be possible to support Apples "Common Crypto Services" instead of >> OpenSSL > [..] > But in general, it sounds like a bad idea. In light of Apple's now-infamous > "goto fail" bug > http://www.zdnet.com/apples-goto-fail-tells-us-nothing-good-about-cupertinos-software-delivery-process-7000027449/ > it would be poor practice to migrate away from a security package that is now > receiving broad and in-depth scrutiny, to one that only has Apple's assurances > behind it. Also given Apple's success rate with security in general > http://online.wsj.com/articles/apple-celebrity-accounts-compromised-by-very-targeted-attack-1409683803 > it seems like a poor choice. Yes, I agree with these concerns - especially for OpenLDAP server deployments. But there are some advantages using the OS platform's mainstream crypto lib for libldap to get access to the OS's own keyring (e.g. when using client certs). E.g. I'd avoid libnss for OpenLDAP servers but PKCS#11 in libnss gives some better access to smartcards. On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options having no or different meaning/features for various crypto libs... Ciao, Michael.
Michael Ströder wrote: > hyc@symas.com wrote: >> gabriel@gritsch-soft.com wrote: >>> would it be possible to support Apples "Common Crypto Services" instead of >>> OpenSSL >> [..] >> But in general, it sounds like a bad idea. In light of Apple's now-infamous >> "goto fail" bug >> http://www.zdnet.com/apples-goto-fail-tells-us-nothing-good-about-cupertinos-software-delivery-process-7000027449/ >> it would be poor practice to migrate away from a security package that is now >> receiving broad and in-depth scrutiny, to one that only has Apple's assurances >> behind it. Also given Apple's success rate with security in general >> http://online.wsj.com/articles/apple-celebrity-accounts-compromised-by-very-targeted-attack-1409683803 >> it seems like a poor choice. > > Yes, I agree with these concerns - especially for OpenLDAP server deployments. > > But there are some advantages using the OS platform's mainstream crypto lib > for libldap to get access to the OS's own keyring (e.g. when using client certs). > > E.g. I'd avoid libnss for OpenLDAP servers but PKCS#11 in libnss gives some > better access to smartcards. OK, that may be nice to have. OpenSSL's engine API already allows such things to be supported dynamically, though. > On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options > having no or different meaning/features for various crypto libs... Indeed. Even moreso if, as you seem to be suggesting, a client library gets built against a different TLS API than the server side. The current libldap infrastructure wouldn't even support such a build. (Although it could, as the original version of modular TLS support allowed all of the libraries to be supported concurrently. But we dropped that feature because there was no sane usecase for it.) The real solution, if there are platform-specific keystores and such that you want to gain access to, is to submit patches for them to the OpenSSL project. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > Michael Ströder wrote: >> On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options >> having no or different meaning/features for various crypto libs... > > Indeed. Even moreso if, as you seem to be suggesting, a client library gets > built against a different TLS API than the server side. The current libldap > infrastructure wouldn't even support such a build. (Although it could, as the > original version of modular TLS support allowed all of the libraries to be > supported concurrently. But we dropped that feature because there was no sane > usecase for it.) Personally I'd even prefer to have completely different LDAP_OPT_X_TLS_* values and configuration directives for the different crypto APIs. In this case one could really distinguish the different cases. E.g. pointing to an OpenSSL CA certificate path is something completely different than a libnss cert7.db/key3.db directory regarding the content even though in both cases the option just is a directory path. IMHO this would avoid a lot of the user/deployer confusion one can see on the mailing lists. Well, for discussing this openldap-devel list would be the better forum. > The real solution, if there are platform-specific keystores and such that you > want to gain access to, is to submit patches for them to the OpenSSL project. Hmm, openssl engine things are not really easy to deal with. I know that PKCS#11 engine for OpenSSL exists. But such a stack has lots of loose ends. Ciao, Michael.