Re: APR_CRYPTO API EXAMPLES

[Reindl Harald]

Am 08.04.2014 02:04, schrieb Miguel Villarreal:
 Hello. Where can I find examples of how to use the APR_CRYPTO API?

multiple times was explained that this is the wrong list
why do you continue with such joke questions?

http://www.catb.org/esr/faqs/smart-questions.html




signature.asc
Description: OpenPGP digital signature

mod_cache thundering herd bug

[Jim Riggs]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50317

While we are at ApacheCon, I would love to address this nasty bug with someone 
familiar with 2.2's mod_cache. Our sites were brought down a few times last 
year before we finally tracked it down to being this particular bug. I am using 
a crude backport of the 2.3 patch (r1023398) in 2.2. It works, but I don't know 
if it is correct.

Can someone look at this one with me? We really need to get this fixed in 2.2, 
because there is NO thundering herd protection at all as things stand right now.

- Jim

added 2.2.27 and 2.4.9 to bugzilla n/t

[Eric Covener]

n/t

Re: agent-based framework for httpd private keys

[Daniel Kahn Gillmor]

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