On Sun 2014-02-09 02:15:37 -0500, Kaspar Brand wrote: > On 07.02.2014 01:58, Daniel Kahn Gillmor wrote: >> As part of the goal of dropping encrypted private key support, have you >> considered using an agent-based framework for private keys? > > I haven't, no, since an important aspect of that goal is to reduce > complexity in code. Dropping ssl_load_encrypted_pkey and friends from > trunk amounts to a reduction of about 5% of mod_ssl's ~15,000 LoC right now. > >> Anyway, with some sort of agent-based approach, you could preserve >> encrypted keys-on-disk (for Joe Orton's examples of admins with access >> to full-machine backups, or secret-keys-on-NFS) while leaving apache >> agnostic about the way the keys get *into* the agent. > > Putting the decrypted keys on a RAM disk (tmpfs etc.) is a much more > straightforward way to achieve this, IMO, with the benefit of being able > to rely on a well-established method for configuring private keys (and > not having to introduce another non-standard layer for performing > private key operations).
i think an agent-based approach (using a secret-key-holding agent in a
separate memory space) would have prevented the exposure of long-term
secret keys in the recent heartbleed attack [0].
While i appreciate that enabling an agent would probably lead to some
code complexity, an agent-based approach does achieve stronger
protection in some contexts than decrypted keys on a RAM disk.
I don't have time to write a patch any time soon for this, but i just
wanted to highlight that i think the idea still has merit.
Regards,
--dkg
[0] http://heartbleed.com/
pgpIORZFVTkAg.pgp
Description: PGP signature
