Re: OpenSSL randomness seeding

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Noah Misch <noah(at)leadboat(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL randomness seeding
Date: 2020-07-30 21:42:16
Message-ID: CCA47A3E-80A8-40DC-A74A-1A0531283EF1@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 26 Jul 2020, at 09:06, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Jul 22, 2020 at 11:31:38PM +0200, Daniel Gustafsson wrote:
>> Thanks for picking it up!
>
> For the archives, the patch set has been applied as ce4939f and
> 15e4419 on HEAD. Thanks, Noah.

Indeed, thanks!

>>> Do you happen to know how OpenSSL 1.1.1 changed its reaction to forks in order
>>> to make the RAND_poll() superfluous? (No need to research it if you don't.)
>>
>> I'm not entirely sure, but I do believe that 1.1.1 ported over the RNG from the
>> FIPS module which re-seeds itself with fork() protection. There was however a
>> bug, fixed in 1.1.1d or thereabouts as CVE-2019-1549, where the fork protection
>> wasn't activated by default.. so there is that. Since that bug was found,
>> there has been tests introduced to catch any regression on that which is
>> comforting.
>
> No idea about this one actually.

I did some more reading and AFAICT it won't be required in 1.1.1+, but it also
won't cause any harm so unless evidence of the latter emerge we may just as
well leave it as an extra safeguard.

Somewhat on topic though, 1.1.1 adds a RAND_priv_bytes function for random
numbers that are supposed to be private and extra protected via it's own DRBG.
Maybe we should use that for SCRAM salts etc in case we detect 1.1.1?

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-30 21:42:19 Re: Missing CFI in hlCover()?
Previous Message Thomas Munro 2020-07-30 21:42:03 Re: Reducing WaitEventSet syscall churn