Re: pgcrypto seeding problem when ssl=on
От | Andres Freund |
---|---|
Тема | Re: pgcrypto seeding problem when ssl=on |
Дата | |
Msg-id | 20121223011105.GC11430@alap2.lan обсуждение исходный текст |
Ответ на | Re: pgcrypto seeding problem when ssl=on (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgcrypto seeding problem when ssl=on
|
Список | pgsql-hackers |
On 2012-12-22 14:20:56 -0500, Tom Lane wrote: > Marko Kreen <markokr@gmail.com> writes: > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah@leadboat.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
В списке pgsql-hackers по дате отправления: