> Am 12.01.2022 um 11:07 schrieb Joe Orton <jor...@redhat.com>:
>
> On Fri, Jan 07, 2022 at 11:34:47AM +0100, Stefan Eissing wrote:
>> A nice new year to everyone!
>>
>> I was looking at the design of https://github.com/h2o/neverbleed which
>> - loads TLS private keys in a separate process
>> - creates EVP_PKEY instances that in the sign callback call into the
>> separate process to create the TLS handshake signature
>>
>> This is surprisingly simple. With a little overhead, it keeps the keys
>> in a separate address space, inaccessible to any exploits in the traffic
>> serving workers.
>>
>> I wonder if it is worthwhile to add something similar to our server.
>
> It's definitely an interesting idea, though needs a caveat that if a
> compromised worker can do private key operations via the process then
> the key is not truly isolated. (That's not to say it's a bad idea, just
> that it's a mitigation/defence-in-depth approach.)
Thanks for looking at this.
Agreed. I am looking for an easy deployable solution that keeps the
keys out of our memory, but still loads them from the file system,
as we do now.
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
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.
Another possible evolution is to make an implementation that uses
a central service in a cluster, so that keys no longer need to be
copied to all cluster nodes. But that goes into very specific site
setups and is probably not worth an implementation in the project.
This is all brainstorming by me as of now. But, as the neverbleed
implementation shows, it seems quite straightforward to achieve the
memory separation.
Cheers,
Stefan
>
> Regards, Joe
>
