On 5/6/20 1:01 PM, Joe Orton wrote: > On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote: >> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote: >>> On 5/4/20 3:49 PM, Joe Orton wrote: >>>> d) SSLRandomSeed. This might have made sense in 1998 but at least with >>>> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd >>>> should not be doing RAND seeding ever. Currently mod_ssl will splat >>>> random stack data, time() and the pid into the RNG state for each new >>>> connection. Unless someone can prove this is valuable and the OpenSSL >>>> PRNG is somehow broken OOTB, I think this code + directive should be >>>> dropped for OpenSSL 1.1.1+, including EGD support etc. >>> >>> Do we drop it only for OpenSSL 1.1.1 or are there other older versions of >>> OpenSSL where this is save to drop? >> >> From https://wiki.openssl.org/index.php/Random_fork-safety it seems like >> there is some reason to believe the <1.1.1 RNG is not safe after fork >> unless you help it. >> >> I was looking at the Fedora default mod_ssl config which does have a >> default "SSLRandom", but the example httpd-ssl.conf shipped does not. So >> *maybe* configuring SSLRandomSeed is useful, but really if it is not >> needed by default we should do something by default, which we don't. > > ^ Apologies for garbled grammar, I meant: > > "if it IS needed by default, we should do something by default" > > ... and we *do* have something configured by default: > > # Note: The following must must be present to support > # starting without SSL on platforms with no /dev/random equivalent > # but a statically compiled-in mod_ssl. > # > <IfModule ssl_module> > SSLRandomSeed startup builtin > SSLRandomSeed connect builtin > </IfModule> > > but if OpenSSL does not have entropy source beyond that provided by > mod_ssl calling getpid() and time() it is IMO far better to fail to > start up. > > So maybe we should still call RAND_status() and fail startup if the PRNG > is not initialized correctly? > I think we should fail startup, it's better to fail then to give the user a false sense of security and use a poor PRNG.
Giovanni
