On Wed, Jan 12, 2022 at 03:37:05PM +0100, Stefan Eissing wrote: > My current, rough idea would be: > > - fork a process, like mod_cgid does, that can be communicated > with over a unix domain socket > - have an ap_hook to load a key and return an opaque key handle > - have an ap_hooks to sign/encrypt/decrypt data for a key handle > > > For mod_ssl that would mean: > - use the hook on loading a key file > - if no handle returned, proceed as now, tell SSL_CTX to load the file > - on handle, construct a EVP_PKEY that proxies its methods to the > new hooks
You can do this already with PKCS#11 and it's already supported in mod_ssl, reinventing that wheel to add another API > Example of how this is done at > https://github.com/h2o/neverbleed/blob/master/neverbleed.c > which AFAICT is used in production at Fastly. > > If we implement this in a new module, that would become usable with > an additional On|Off directive and no changes to SSL configs. > > > You should be able to deploy something like this with PKCS#11, e.g. > > softhsm, p11-kit can proxy PKCS#11 over a Unix domain socket, there are > > probably more solutions out there. > > With the proposed hooks interface, one could do an implementation using soft > or > hard hsms. But that would require changing mod_ssl configs as then the > configuration would need to specify keys by an id other than file names. etc. > etc. Reinventing PKCS#11 as an ap_* level API is hardly without cost, though, so I wouldn't wave that away against some "etc etc" costs that users would need to tweak configs for. When I look at this problem from 10,000ft I see two parts: a) daemon which loads keys and offers key operations over an AF_UNIX interface b) interface to (a) from SSL_* layer Importantly, both of these seem equally useful in e.g. exim as they are in httpd. You get (b) from supporting PKCS#11 which is already done in mod_ssl/OpenSSL. I don't know how much you can get (a) in a convenient way for users, but as a project it mostly orthogonal to httpd except for some startup integration stuff. Regards, Joe
