[openssl-dev] Work on a new RNG for OpenSSL

[Peter Waltenberg]

The bad case I'm aware of is the fork() one as it's critical that the RNG 
state diverge on fork(). Without that you can get some very nasty 
behaviour in things like TLS servers. Some of which have a thread pool + 
fork() model to handle increasing load.

While ideally you'd do a complete reseed, just different state in each RNG 
is a LOT better than nothing, and even PID + whatever else you can 
scrounge up will help a lot. Even the high res counters available on most 
current CPU's would help there because forking multiple processes isn't 
quite synchronous.

I don't think 'telling the user to fix it' is a particularly good option 
in these cases as in general the user will be even less capable of dealing 
with this than OpenSSL. By all means warn the users that behaviour may not 
be ideal, but do your best first.

Peter





From:   Paul Kehrer <paul.l.kehrer at gmail.com>
To:     "openssl-dev at openssl.org" <openssl-dev at openssl.org>
Date:   24/08/2017 07:13
Subject:        Re: [openssl-dev] Work on a new RNG for OpenSSL
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org>



On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev (
openssl-dev at openssl.org) wrote:

I think the safest thing is for us to not change the default. Programs 
that know they are going to fork can do the right/safe thing. It would be 
nicer if we could automatically always do the right thing, but I don’t 
think it’s possible. 


It appears the current position is that since there will be edge cases 
where a reseed would fail (thus either halting the RNG or silently not 
reseeding it) that we should not attempt to reseed? I would argue it is 
better to attempt to reseed and document that edge cases may need to 
reseed themselves. This dramatically narrows the window from "everybody 
needs to do it" to "users in certain scenarios that are becoming rarer by 
the day need to do it". Given that backwards compatibility is a concern 
maybe failure to reseed on fork should only drop an error on the child 
process's error queue though? That behavior could potentially be a 
separate flag that OpenSSL uses by default (OPENSSL_TRY_TO_INIT_ATFORK), 
and then OPENSSL_INIT_ATFORK can be more strict about reseed failures if 
desired.

-Paul-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=fF3EsvxEsVa_Gqvi75hhE7fVtPzma348fsGdbb_GMLc&s=OhHmJAPRZokV7vWQaJy75wCYUxEWJLfAf79YJH6Mhao&e= 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170824/2ab4af08/attachment.html>