agent-based framework for httpd private keys [was: Re: SSL_CTX_get_{first,next}_certificate]

[Daniel Kahn Gillmor <dk...@fifthhorseman.net>]

On 02/06/2014 12:35 AM, Kaspar Brand wrote:
> On 05.02.2014 18:13, Falco Schwarz wrote:
>> Kaspar, I ran into another issue when using an encrypted private key and "SSLOpenSSLConfCmd PrivateKey".
>> Again it fails to load the encrypted private key with the following errors:
> 
> That's by design, see [1]. Eventually I'd like to drop support for
> encrypted private keys from trunk.

As part of the goal of dropping encrypted private key support, have you
considered using an agent-based framework for private keys?

As a point of reference, OpenSSH added agent-based host key support for
sshd on 2013-07-20.

tTe basic model is:

 0) there is a running agent that holds secret key material and listens
on a socket (unix-domain sockets are nice because of the possibility of
tight filesystem permission control)

 1) the daemon (httpd, sshd) knows how to talk to the agent, to request
a list of available keys, and to request signing or decryption
operations to be done by the keys.

 2) the agent has a set of rules that govern when and how to obey a
specific request for signing or decryption operations

 3) the sysadmin has an interface to load password-protected keys into
the agent.

You can also run the agent under a different user account than the web
server, so that a runaway web server process wouldn't have access to the
secret key material without some other privilege escalation.  And you
can commit to a very small-footprint agent, with less room for bugs and
exploits, as compared to the entire modular webserver.

PKCS#11 is one formalization of this approach (though i think that PKCS
#11's shared object interface itself is pretty problematic in today's
multi-core/multi-threaded/multi-process architectures).

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.

	--dkg

Re: agent-based framework for httpd private keys

[Reindl Harald <h....@thelounge.net>]

Am 09.02.2014 08:15, schrieb Kaspar Brand:
> 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

may i notice as server-admin that i am not willing to run whatever agent
additional on headless machines and most admins out there do the same

first rule:  stop and disable anything
second rule: now enable the things you really need
third rule:  consider to replace software which pulls to much here

Re: agent-based framework for httpd private keys

[Daniel Kahn Gillmor <dk...@fifthhorseman.net>]

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/

Re: agent-based framework for httpd private keys

[Kaspar Brand <ht...@velox.ch>]

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).

Kaspar