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