_ _ _ __ ___ ___ __| | ___ ___| | mod_ssl | '_ ` _ \ / _ \ / _` | / __/ __| | Apache Interface to OpenSSL | | | | | | (_) | (_| | \__ \__ \ | www.modssl.org |_| |_| |_|\___/ \__,_|___|___/___/_| ftp.modssl.org |_____| _____________________________________________________________________________ ``It wasn't raining when Noah built the ark.'' -- Howard Ruff WISHES The following is a list of any types of wishes the users or the author of mod_ssl wants to see in future releases. *) Lai Yiu Fai : ``Have anyone think about incorporating LDAP as the backend storage of certificate database for mod_ssl? Right now, it uses SSLFakeBasicAuth to translate client certificate into a basic authorization header for authentication. It would be rather clumsy and not easy to maintain. It would be great if mod_ssl can follow Netscape Server in handling SSL client authentication: 1) extract the client certificate subject 2) match predefined attributes e.g. mail, cn, uid, ... from X.509 subject 3) search against LDAP with these filters 4) compare the certificate attribute with the matched DN 5) if compare OK, authentication succeed.'' Possible LDAP libraries to use: o The OpenLDAP Project [BEST] http://www.OpenLDAP.org/ o The reference implementation LDAP 3.3: http://www.umich.edu/~dirsvcs/ldap/ldap.html o Netscape Directory SDK http://www.mozilla.org/directory/ Ideas and hints can be taken from: o LDAP basic authentication module based on Norman Richards: http://www.cs.utexas.edu/users/orb/projects/mod_auth_ldap.c State: Good suggestion, but this has to be contributed by someones else, because the author has no experiences with LDAP. Someone else now started to work on this. *) Ralf S. Engelschall: ``I want an Apache+mod_ssl Test Suite. Perhaps via OpenSSL's s_client or Perl's OpenSSL interface?'' Status: Will be done in the future but I currently don't know for which release. At least I'll start using this locally for development. *) Andrew Ford : ``One way I had thought of for supporting pass-phrases more securely on machines that are exposed to the Internet was to start the web server from another system situated behind a firewall. The public system might have to have a way of notifying the internal system that the web server should be started or restarted (or maybe the internal machine would monitor the public machine continuously). A process on the internal machine could start the web server remotely using a combination of SSH and "expect" to send the pass-phrase. In this way the pass-phrase is not stored on the public machine. I've not actually implemented this -- although I have used SSH and expect for inter-process communication through firewalls without operator intervention -- but I am thinking of something like this sort of setup for one of my clients. Of course one could possibly extend mod_ssl so that the use of some sort of secure channel to a separate co-process (on another system) to obtain the pass phrase was built-in. But if you are worried about a public server being compromised then you cannot really trust any configuration files stored on the public system and everything should probably be initiated from the more-secure, internal system.'' Status: It's too much to implement this directly inside Apache+mod_ssl, so mod_ssl since 2.1 provides at least a plug-in interface (`SSLPassPhraseDialog exec:/path/to/program') which can be used to connect an external program to mod_ssl which then provides the pass phrase. But it would be nice if someone now at least contributes such a program (perhaps a Perl script) which receives the pass phrase via SSH or other mechanism from a remote machine in a secure way. *) Andrew Ford : ``Another variant on this would be to allow 'SSLPassPhraseDialog fd1 fd2', i.e. Apache/ssl_mod started with file descriptors fd1 and fd2 open (for reading and writing respectively) on a pipe to the external process. In this scenario the script that starts Apache (securely) would ensure that there was a pipe open that would provide the pass phrase (obviously these file desciptors should be closed when child server processes are started). I think this would be my preferred option.'' Status: This filedescriptor passing is a nice idea but not very portable. But perhaps we can add it in the future... *) Holger Reif and Ralf S. Engelschall: The gcache stuff from mod_ssl 2.0 was too buggy, but the idea itself (using an external program for the cache) _can_ be interesting for mod_ssl 2.2 when one things about webclusters and load balancing. Perhaps we can rewrite a more robust gcache with a more secure network protocol. tvaughan@aventail.com: What about maintaining a persistent connection to a gcache server on a per-child or per-thread basis within Apache? And possibly having a list of gcache servers to connect to for fail-over? And possibly connecting to a "load-balancer" which then tells mod_ssl which gcache server to connect to? Here is what RSE would do: - Write a generic caching package consisting of a caching server and a caching client. - The server is a multithreaded beast which uses a high-performance hash library for storing the stuff in the heap. - The client is a library providing an API which handles all the socket details and server correspondence. - The client library then is used inside mod_ssl from within ssl_engine_scache.c. - The whole stuff should be _totally_ independent of mod_ssl or SSL, i.e. it should allow one to cache any data, not only SSL sessions. And so it should be released as a separate package similar to MM. Apache+mod_ssl just uses it. - For the hashing library I would use the "table" library I already used in mod_ssl. For the threading I would use NPS for maximum portability. Status: Not for 2.6, perhaps for 2.7 or 2.8. *) Ralf S. Engelschall: ``We should clean up the directive names related to certificates.''