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. > That's a good question. I believe that if one actually do use RAND_cleanup as > a re-seeding mechanism then that can break FIPS enabled OpenSSL installations > as RAND_cleanup resets the RNG method from the FIPS RNG to the built-in one. > I > would be inclined to follow the upstream recommendations of using RAND_poll > exclusively, but I'm far from an expert here. RAND_cleanup() can cause a failure telling that the RNG state is not initialized when attempting to use FIPS in 1.0.2. This is not officially supported by upstream AFAIK, and those APIs have been dropped later in 1.1.0. And FWIW, VMware's Photon actually applies some custom patches in this area: https://github.com/vmware/photon/tree/master/SPECS/openssl openssl-drbg-default-read-system-fips.patch is used to enforce the initialization state of FIPS for example. Anyway, I would just stick with the wiki recommendation. >> 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. -- Michael
signature.asc
Description: PGP signature
