[mod_gnutls-devel] mod_gnutls + pkcs11 = less data leaked (?)

[Nikos Mavrogiannopoulos]

On Fri, Apr 11, 2014 at 4:17 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
>>  I was thinking ways of how a memory leakage in mod_gnutls could have
>> prevented revealing secrets such as the server's private key, and I
>> think that this could be "easily" doable if mod_gnutls would support
>> pkcs11 keys (from a quick glimpse I think it doesn't yet). If it would
>> support it, then one could use a software security module such as:
>> http://www.clizio.com/lsmpkcs11.html
>> and separate the private key operations from the server process. I put
>> "easily" on quotes because unfortunately lsm-pkcs11 seem to be a dead
>> project and more modern modules like softhsm [0] don't use any
>> isolation between the key operations and the calling process.
>> Nevertheless, I think it would be a good feature to have.
> yes, i agree!  I actually nudged the mod_ssl folks about this sort of
> thing (though not in pkcs11 exactly) recently.
> I've recorded this feature suggestion here:
>  https://mod.gnutls.org/ticket/23
> I'd be happy to see patches or even a proposed API for it.

The easiest for pkcs11 support would be to allow pkcs11 urls in the
key file directive, use gnutls_pkcs11_privkey_import_url() to import
it, and the on the callback to read the certificate set the
gnutls_pkcs11_privkey_t as key. That could be tested with softhsm
(it's a pretty good implementation).

That's pretty much the easy part. The hard part is to find a software
module like pkcs11-lsm that enforces separation between keys and the
server.

An alternative could be to fork() out a custom security-module as done
in ocserv [0] and use that. Although that would be simpler for now, I
think the approach with pkcs11 is better.

[0]. http://git.infradead.org/ocserv.git/blob/HEAD:/src/sec-mod.c

regards,
Nikos