Re: pgcrypto seeding problem when ssl=on

On 2012-12-22 14:20:56 -0500, Tom Lane wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
> > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> >> How about instead calling RAND_cleanup() after each backend fork?
>
> > Not "instead" - the gettimeofday() makes sense in any case. Considering
> > that it's immediate problem only for pgcrypto, this patch has higher chance
> > for appearing in back-branches.
>
> > If the _cleanup() makes next RAND_bytes() call RAND_poll() again?
> > Then yes, it certainly makes sense as core patch.
>
> I thought some more about this, and I think there is a pretty strong
> objection to this version of the patch: it *only* fixes the
> lack-of-randomness problem for pgcrypto users. Any other third-party
> code depending on the OpenSSL PRNG will have the same problem.
> Furthermore, it's not even obvious that this patch fixes it for all
> pgcrypto functions --- it probably is all right today, since I assume
> Marko remembers all the connections in that code, but it would be easy
> to miss the problem in future additions.
>
> I believe that we'd be better off doing something in postmaster.c to
> positively ensure that each session has a distinct seed value. Notice
> that BackendRun() already takes measures to ensure that's the case for
> the regular libc random() function; it seems like a reasonable extension
> to also worry about OpenSSL's PRNG.
>
> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> though, as that seems like it'll guarantee that each session starts out
> with only a minimal amount of entropy. What seems to me like it'd be
> most secure is to make the postmaster do RAND_add() with a gettimeofday
> result after each successful fork, say at the bottom of
> BackendStartup(). That way the randomness accumulates in the parent
> process, and there's no way to predict the initial state of any session
> without exact knowledge of every child process launch since postmaster
> start.

I am entirely unconvinced that adding in a gettimeofday() provides more
entropy than what openssl gathers internally after a
RAND_cleanup(). gettimeofday() will yield the same result in close
enough forks on a significant number of systems whereas openssl should
use stuff like /dev/urandom to initialize its PRNG after a cleanup.

I think a better solution might be to use up some entropy in the
postmaster *before* doing a fork and then mix in the pid +
gettimeofday()after the fork.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services