A couple of reports and check-in messages like

  Postgres / pgcrypto CVE-2013-1900
  http://bugs.ruby-lang.org/issues/4579
  http://www.exim.org/lurker/message/20130402.171710.92f14a60.fi.html

suggests that OpenSSL's PRNG should be reset or re-seeded after fork(). Otherwise child processes can generate the same or similar pseudo random values.

Python doesn't have an API to run code before and after fork yet. The patch uses pthread_atfork() for the task. It's available on all pthread platforms -- which are all official supported platforms that have fork(), too.

The patch doesn't use RAND_cleanup() like Postgres because child process would hav to initial the PRNG again by opening and reading from /dev/urandom. The atfork prepare hook pulls from random bytes from the PRNG and stores them in a static buffer. The child handler seeds the PRNG from that buffer + pid + current time. PID and current time are mixed into the state to extenuate race conditions.

Are there any uses of the OpenSSL PRNG from Python?
Is the PRNG used for SSL session keys, or another mechanism?

The ssl module exposes OpenSSL's PRNG and advertises the API as secure CPRNG: http://docs.python.org/3/library/ssl.html#random-generation

OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections.

> The ssl module exposes OpenSSL's PRNG and advertises the API as secure
> CPRNG: http://docs.python.org/3/library/ssl.html#random-generation

AFAICT, Python's PRNG isn't reset after fork, so I don't think OpenSSL's
should be reset.
OTOH, multiprocessing does reseed the random module after fork, so it
should also do so for the ssl module if already loaded.

We may add a note in the ssl docs stating that it's better to reseed
after fork().

Python doesn't have a builtin PRNG. We use the OS's CPRNG such as /dev/urandom or CryptGenRandom(). Both use a system wide state and are not affected by process state. OpenSSL's PRNG is different because it uses an internal state. AFAIK it only polls the system's entropy poll when the PRNG is used for the first time.

It's not only multiprocessing. What about forking webservers etc. that use HTTPS?

> Python doesn't have a builtin PRNG.

Of course it does. It's in the random module, and you can seed() it:

>>> random.seed(5)
>>> random.random()
0.6229016948897019
>>> random.random()
0.7417869892607294
>>> random.seed(5)
>>> random.random()
0.6229016948897019

See e.g. issue12856. And the multiprocessing module:
http://hg.python.org/cpython/file/92039fb68483/Lib/multiprocessing/forkserver.py#l195

> We use the OS's CPRNG such as /dev/urandom or CryptGenRandom().

"We"?

> It's not only multiprocessing. What about forking webservers etc.
> that use HTTPS?

Well, are they affected? I haven't understood your previous answer.
("OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections")

Note that it seems debatable whether it's an OpenSSL bug:
http://www.openwall.com/lists/oss-security/2013/04/12/3

Am 15.08.2013 15:14, schrieb Antoine Pitrou:
>> Python doesn't have a builtin PRNG.
> 
> Of course it does. It's in the random module, and you can seed() it:

Now you are nit-picking. Although random is a PRNG, it is not a CPRNG.
I'm clearly talking about the integrity of a CPRNG here.

>> We use the OS's CPRNG such as /dev/urandom or CryptGenRandom().
> 
> "We"?

Python's os.urandom() and _PyOS_URandom().

> Well, are they affected? I haven't understood your previous answer.
> ("OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections")

Yes, they are are affected. A forking HTTPS server does:

1) listen() on a TCP port
2) accept() new TCP connection
3) fork() a child process to handle request
4) do SSL handshake in the child process
5) read/write data in child process

When the OpenSSL's CPRNG is already initialized before 3) than all child
processes created by 3) will have almost the same PRNG state. According
to http://bugs.ruby-lang.org/issues/4579 the PRNG will return the same
value when PID numbers are recycled.

> Note that it seems debatable whether it's an OpenSSL bug:
> http://www.openwall.com/lists/oss-security/2013/04/12/3

It probably is an OpenSSL bug but the declaration doesn't help us. It's
not the first time Python has to work around OpenSSL, e.g. #18709.

> When the OpenSSL's CPRNG is already initialized before 3) than all child
> processes created by 3) will have almost the same PRNG state. According
> to http://bugs.ruby-lang.org/issues/4579 the PRNG will return the same
> value when PID numbers are recycled.

Thanks. Here is some discussion of the reseeding strategy:
http://marc.info/?l=openssl-dev&m=130432419329454&w=2

More precisely, instead of reseeding in the child, you can simply
perturb the PRNG with a constant in the parent, to make sure the same
PRNG state doesn't get re-used.

This issue was already discussed in the atfork issue:
http://bugs.python.org/issue16500#msg179838

See also:
http://www.openwall.com/lists/oss-security/2013/04/12/3
"I believe it is wrong to fix this in PostgreSQL.  Rather, this is a
bug in the OpenSSL fork protection code.  It should either install a
fork hook, or reseed the PRNG from /dev/urandom if a PID change is
detected."

Another link:
http://article.gmane.org/gmane.comp.encryption.openssl.user/48480/match=does+child+process+still+need+reseeded+after+fork

Here is a patch that is based on Apache's mod_ssl code. mod_ssl perturbs the PRNG state more often but I think that's overkill for Python.

The new patch only affects the PRNG state of the child process. In my opinion it is the better way to solve this issue. The RAND API does some internal locking. Bad things might happen if one thread of a process calls fork() while another is in the middle of a locked RAND operation.

The patch looks fine on the principle, but you should add a test.

2013/8/17 Christian Heimes <report@bugs.python.org>:
> Here is a patch that is based on Apache's mod_ssl code. mod_ssl perturbs the PRNG state more often but I think that's overkill for Python.
>
> The new patch only affects the PRNG state of the child process. In my opinion it is the better way to solve this issue. The RAND API does some internal locking. Bad things might happen if one thread of a process calls fork() while another is in the middle of a locked RAND operation.

Ouch, this would mean making the interpreter prone to deadlock/crash
(since the atfork hook is not async-signal safe) :-\

openssl_prng_atfork3.patch: Why not using seconds (only micro or
nanoseconds) in the seed? Add a few more bits should not reduce the
entropy. OpenSSL does hash all these bytes anyway.

+#if 1
+    fprintf(stderr, "PySSL_RAND_atfork_child() seeds %i bytes in %i\n",
+            (int)sizeof(seed), seed.pid);
+#endif

This should be removed from the final patch ;-)

The patch is specific to pthread. Do we need something similar on
Windows. Windows has no fork, but I don't know if OpenSSL CPRNG state
can be inherited somehow? Does Python support other platforms (other
than pthread or Windows)?

Instead of using pthread_atfork(), we can add an hook in the Python
binding of OpenSSL checking the pid. I don't know which functions
should be modified. ssl.RAND_bytes() is probably not enough :-)

The lastest patch mixes seconds into the time field of seed.

Python 3.3+ support only NT and POSIX threads. 2.7 and 3.2 have GNU pth and other threading API but I neither have a system to test other threading libs nor the motivation to port my patch to an ancient threading library.

It's not just RAND_bytes(). OpenSSL's PRNG is also used by OpenSSL internally, e.g. as entropy source for SSL/TLS handshakes. How many function do you want to patch?

PySSL_RAND_atfork_child(void) can be simplified by calling
_PyTime_gettimeofday(). This function uses the most(*) accurate
function and already implements fallbacks on error.

(*) _PyTime_gettimeofday() does not use clock_gettime() because of a
linker issue: Python is not linked to librt, which is required to get
clock_gettime() on Linux with glibc < 2.17. So you get a few less bits
of entropy, but does it really matter? If it matters, you have
probably to use a better random of entropy than the system time...

Anyway, it would be easier to move the _PyTime_timeval and similar
structures into the seed structure instead of shifting bits.

Thanks Victor, it sounds like a good suggestion. I have modified my patch to use _PyTime_gettimeofday(). Python 2.7 doesn't have _PyTime_gettimeofday() so I'm going to use time(NULL).

openssl_prng_atfork5.patch:

- you should use RAND_pseudo_bytes() instead of RAND_bytes() in the unit test, to not skip the test depending on the entropy
- the change in Misc/NEWS is strange
- please remove dead code ("#if 0")
- PySSL_RAND_atfork_child() comment is wrong, it is no more able to get time with a nanosecond resolution (write "(microseconds or seconds)")
- can you explain the choice of "char stack[72]" (72 bytes): why no more, why not less?

New changeset 8e1194c39bed by Christian Heimes in branch '3.3':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/8e1194c39bed

New changeset 49e23a3adf26 by Christian Heimes in branch 'default':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/49e23a3adf26

New changeset 2e6aa6c29be2 by Christian Heimes in branch '2.7':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/2e6aa6c29be2

I have taken care of Antoine's and Victor's reviews. The fix has landed in Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a security fix (although I don't consider its severity as high).

> Christian Heimes added the comment:
>
> I have taken care of Antoine's and Victor's reviews. The fix has landed in Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a security fix (although I don't consider its severity as high).

There's still the #if 0 in the patch you committed.

And basically, because PySSL_RAND_atfork_child() is not async-signal
safe, the interpreter is now subject to random deadlocks/crash in
multi-threaded processes. I personally don't consider this a security
fix...

3.52 +#if 0
    3.53 +    fprintf(stderr, "PySSL_RAND_atfork_child() seeds %i
bytes in pid %i\n",
    3.54 +            (int)sizeof(seed), seed.pid);
    3.55 +#endif

Don't you want to remove this debug code?

     1.8 +    def test_random_fork(self):
     1.9 +        status = ssl.RAND_status()
    1.10 +        if not status:
    1.11 +            self.fail("OpenSSL's PRNG has insufficient randomness")

The test uses ssl.RAND_pseudo_bytes(), the check on ssl.RAND_status()
must be removed.

Am 21.08.2013 14:08, schrieb Charles-François Natali:
> And basically, because PySSL_RAND_atfork_child() is not async-signal
> safe, the interpreter is now subject to random deadlocks/crash in
> multi-threaded processes. I personally don't consider this a security
> fix...

Which part of the function is not async-signal safe? It doesn't interact
with any file descriptors nor does it use any syscalls except for
getpid() and time().

Python's _ssl module doesn't re-initialize its locks on fork. That's an
outstanding issue that is not related to the change.

> Which part of the function is not async-signal safe? It doesn't interact
> with any file descriptors nor does it use any syscalls except for
> getpid() and time().

gettimeofday() and RAND_add()

The functions which are guaranteed to be async-signal safe are listed here:
https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers

And here's what David Butenhof says about pthread_atfork():
"""
The real answer is that pthread_atfork() is a completely useless and stupid
mechanism that was a well intentioned but ultimately pointless attempt to
carve a "back door" solution out of an inherently insoluable design
conflict.
"""

More here:
https://groups.google.com/forum/#!msg/comp.programming.threads/ThHE32-vRsg/3j-YICgSQzoJ

IMO it's really an openssl issue, and it should be fixed there (mainly
because they are the only one in position of setuping a safe
atfork-hook, like the glibc does for malloc & co).

Do you have a proposal for a better way to fix the issue? I don't think that we can hope for a fix from OpenSSL.

> Do you have a proposal for a better way to fix the issue? I don't
> think that we can hope for a fix from OpenSSL.

Instead of reseeding in the child, you can perturb the state in the parent
after fork. As far as I understand, only the "child" callback in
pthread_atfork() needs to be async-signal-safe:

"It is suggested that programs that use fork() call an exec function
very soon afterwards in the child process, thus resetting all states.
In the meantime, only a short list of async-signal-safe library
routines are promised to be available."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html

2013/8/21 Antoine Pitrou <report@bugs.python.org>:
> Instead of reseeding in the child, you can perturb the state in the parent
> after fork.
> As far as I understand, only the "child" callback in pthread_atfork() needs to be async-signal-safe:

That's not completely true: fork() is supposed to be async-signal
safe: it can be called from a signal handler (I wouldn't do this, but
that's allowed), but most notably, it can be called after another
fork().
For example, let's say you have a multi-threaded process, and it
fork()s. If you reseed from "parent" (right before or after fork),
then it's safe. But once you're in the child process, the process
state is "unsafe" until exec(), i.e. you can only call async-signal
safe functions. So if you fork() again before exec() - which is
common, e.g. if you use the double-fork() idiom for daemons - then
you'll call the reseed in an unsafe context. In other words, the
"parent" callback is called in the context of a "child" callback in
the child process.

So it's not really safe either, although the window is narrower.

The only 100% safe way I can think of - apart from ignoring the
problem - would be to check if the PID has changed upon entering ssl
function (caching it to avoid calling getpid() everytime), keeping in
mind that there will still be the risk of deadlock/crash anyway if the
user enters the ssl library before exec()...

Another, probably cleaner way would be to finally add the atfork()
module (issue #16500), and register this reseed hook (which could then
be implemented in ssl.py).

forking() in a multi-threaded context is an unsolvable problem...

On 21/08/2013 3:46pm, Charles-François Natali wrote:
> Another, probably cleaner way would be to finally add the atfork()
> module (issue #16500), and register this reseed hook (which could then
> be implemented in ssl.py).

Wouldn't that still suffer from the double-fork() issue?

> [snip insightful explanation]
> So it's not really safe either, although the window is narrower.

Gosh. Well, the narrower window would be fine with me :-)

Oh heck, signal, threads and fork really don't mix. :(
Under which condition can a non-async safe function cause trouble? Is it just fork() inside a signal handler or can an incoming signal during fork() also cause havoc?

The OpenSSL PRNG is only buggy when used in a forking application where the master process initializes the PRNG but never uses it. All child processes inherit the same state. OpenSSL tries to work around the problem by feeding the PID into the PRNG state. But as soon as PIDs get recycled, subsequent child processes get the same random numbers.

Antoine's proposal works, too, because it perturbs the master's PRNG state regularly.

>> Another, probably cleaner way would be to finally add the atfork()
>> module (issue #16500), and register this reseed hook (which could then
>> be implemented in ssl.py).
>
> Wouldn't that still suffer from the double-fork() issue?

Not for the "officially" supported way of creating child processes,
subprocess, since it calls fork() + exec() from C.
The problem with pthread_atfork() is that it would make the whole
interpreter non-safe even for correct code paths that call fork() +
exec(), which is not the case now.

Not reseeding with pthread_atfork() or atfork module, but only when
the ssl library is entered, just means that if a deadlock must occur,
it will only occur if the process re-enters the ssl library after
fork().

> Under which condition can a non-async safe function cause trouble? Is it just fork() inside a signal handler or can an incoming signal during fork() also cause havoc?

Actually, it doesn't need a signal to cause havoc: imagine that thread
A is inside an ssl function, holding a mutex protecting process-wide
internal ssl data. Then, thread B forks: in the child process, the ssl
mutex is already held (since the adress space is COW), so upon next
ssl library call in the child, the process will deadlock (trying to
acquire a mutex already held). That's an example with lock, but the
same holds if the library uses a global/static variable, etc. As an
approximation, sync-signal safe means "reentrant" (async-signal safe
comes from the fact that such restrictions apply to signal handler,
for the exact same reasons).

So you can pretty much only use reentrant functions between fork() and
exec() in a multi-threaded process (i.e. no malloc(), no strtok()...).
Which basically means that you can't run Python code at all between
fork() and exec() in a multi-threaded code.

New changeset 39c9dbed3aa1 by Christian Heimes in branch '3.3':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/39c9dbed3aa1

New changeset 25e05147d662 by Christian Heimes in branch 'default':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/25e05147d662

New changeset d542f905081a by Christian Heimes in branch '2.7':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/d542f905081a

New changeset 6ec43643c54f by Christian Heimes in branch '3.3':
Issue #18747: Update Misc/NEWS to reflect the latest changeset.
http://hg.python.org/cpython/rev/6ec43643c54f

New changeset 956261a143eb by Christian Heimes in branch 'default':
Issue #18747: Update Misc/NEWS to reflect the latest changeset.
http://hg.python.org/cpython/rev/956261a143eb

New changeset 14490ced507e by Christian Heimes in branch '2.7':
Issue #18747: Update Misc/NEWS to reflect the latest changeset.
http://hg.python.org/cpython/rev/14490ced507e

Some typos on last commit....

"current time (miliseconds or seconds) and an uninitialized arry."

should be

"current time (miliseconds or seconds) and an uninitialized array."


"instead of a child handler because fork() is suppose to be async-signal"

should be

"instead of a child handler because fork() is supposed to be async-signal"


"A pthread_atfork() parent handler is used to seeded the PRNG with pid, time"

should be

"A pthread_atfork() parent handler is used to seed the PRNG with pid, time"

Thanks, that's embarrassing. :( I'm going to install a spell checker ...

PySSL_RAND_atfork_parent() still uses getpid(). This number is not
very random in the *parent* process :-)

> STINNER Victor added the comment:
>
> PySSL_RAND_atfork_parent() still uses getpid(). This number is not
> very random in the *parent* process :-)

:-)

IMO this patch has been rushed in and should be reverted for now.
It's still not async-signal safe, had typos, plus this problem noted by Victor.

> IMO this patch has been rushed in and should be reverted for now.

Agreed.

Am 22.08.2013 15:20, schrieb STINNER Victor:
> 
> STINNER Victor added the comment:
> 
> PySSL_RAND_atfork_parent() still uses getpid(). This number is not
> very random in the *parent* process :-)

That's fine and doesn't diminish the properties of the PRNG. In fact the
patch could use a hard coded value to perturb the PRNG. It's only
important to modify the PRNG state of the *parent* process so that
recycled PIDs of *child* processes don't lead to repeated pseudo-random
values.

PID, time and stack are just hard-to-guess properties of the process.
That's all.

Yet another good blog post about the issue:

OpenSSL PRNG Is Not (Really) Fork-safe
http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/

> IMO this patch has been rushed in and should be reverted for now.
> It's still not async-signal safe, had typos, plus this problem noted
> by Victor.

That's not really a problem. You merely have to *perturb* the random
state in the parent, so that the next child gets a different initial
state. As pointed out in a mailing-list message, mixing in a constant
could be enough to perturb the state.

As for not being async-signal safe, it's only in the double fork()
case, which is much less of an issue IMO.

>> PySSL_RAND_atfork_parent() still uses getpid(). This number is not
>> very random in the *parent* process :-)
>
> That's fine and doesn't diminish the properties of the PRNG. In fact the
> patch could use a hard coded value to perturb the PRNG. It's only
> important to modify the PRNG state of the *parent* process so that
> recycled PIDs of *child* processes don't lead to repeated pseudo-random
> values.

Yeah, it doesn't weaken the PRNG, but since we're using current time
and stack content to reseed it, using the parent PID which doesn't
change doesn't bring much (since we chose to add entropy and not just
a constant, which would be sufficient as you noted).

Anyway, for those interested, here's a reproducer.

On Aug 21, 2013, at 11:49 AM, Christian Heimes wrote:

>I have taken care of Antoine's and Victor's reviews. The fix has landed in
>Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a
>security fix (although I don't consider its severity as high).

I'd like to get this into 2.6.  I'll apply the patch after I fix my
environment so it can actually build 2.6 with ssl enabled.  I'll follow up
here with status.

Oh i forgot that i wrote a patch for openssl:
https://bitbucket.org/haypo/hasard/src/tip/patches/openssl_rand_fork.patch

New changeset 8b962e831ff0 by Christian Heimes in branch '3.3':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/8b962e831ff0

New changeset 7b1da249ab6d by Christian Heimes in branch 'default':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/7b1da249ab6d

New changeset 3f30c281eb1c by Christian Heimes in branch '2.7':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/3f30c281eb1c

blocker for 2.6.9

After further contemplation and without objection from __ap__ and Crys on IRC, I am de-targeting this for 2.6.  I won't apply it for 2.6.9.

I can't follow all this.  Is this considered fixed in 3.4 or not?

It's considered fixed but we have seen issues. The issues are tracked in #19227. AFAIK the fixed hasn't landed in 3.2 yet. I'm removing 2,7, 3.3 and 3.4 from the versions list.

Well, I don't mean to be a pain, but I still think this patch
shouldn't have been applied: it makes fork() not async-safe, which
can trigger hard to debug, random bugs (#19227 might or might not be
a direct consequence).

at the very least, I still it shouldn't have been backported.

#19227 must be solved before anything is backported to the security branches.

New changeset 5942eea8cf41 by Christian Heimes in branch '3.3':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL re-seeding
http://hg.python.org/cpython/rev/5942eea8cf41

New changeset cd4007fb9c7e by Christian Heimes in branch '3.3':
Issue #18747: document issue with OpenSSL's CPRNG state and fork
http://hg.python.org/cpython/rev/cd4007fb9c7e

New changeset 705f2addd0f0 by Christian Heimes in branch 'default':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL re-seeding
http://hg.python.org/cpython/rev/705f2addd0f0

New changeset 4d761ce0ac74 by Christian Heimes in branch '2.7':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL re-seeding
http://hg.python.org/cpython/rev/4d761ce0ac74

New changeset 22e166d5c4c7 by Christian Heimes in branch '2.7':
Issue #18747: document issue with OpenSSL's CPRNG state and fork
http://hg.python.org/cpython/rev/22e166d5c4c7

New changeset ad779da9e351 by Christian Heimes in branch '2.7':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL re-seeding
http://hg.python.org/cpython/rev/ad779da9e351

New changeset 4e6aa98bb11c by Christian Heimes in branch '3.3':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL re-seeding
http://hg.python.org/cpython/rev/4e6aa98bb11c

> It probably is an OpenSSL bug but the declaration doesn't help us.
> It's not the first time Python has to work around OpenSSL, e.g. #18709.

Sorry to dig up an old issue. But here's some reading on it if interested.

Ben Laurire pushed a patch to mix in PID and time. The PID was already being used, so the patch adds the time. See "Mixing time into the pool", http://www.mail-archive.com/openssl-dev@openssl.org/msg33012.html. And the commit: https://github.com/openssl/openssl/commit/3cd8547a2018ada88a4303067a2aa15eadc17f39.

OpenSSL added a wiki page for reading on the subject: http://wiki.openssl.org/index.php/Random_fork-safety.

Is this really an enhancement request or should it be a security issue?  Which versions if any actually need work doing on them?

New changeset bdf73458df5f by Christian Heimes in branch '3.2':
Issue #18747: document issue with OpenSSL's CPRNG state and fork
https://hg.python.org/cpython/rev/bdf73458df5f

Now that the default PRNG of the 'random' package is automatically reseeded at fork, wouldn't it make sense to reseed the OpenSSL seed as well?

(At the same time the OpenSSL wiki states [1] that "The situation has changed greatly, starting with OpenSSL 1.1.1 which completely rewrote RNG. The concerns [of fork unsafety] do not really apply any more".)

[1] https://wiki.openssl.org/index.php/Random_fork-safety

The issue is closed. If you want to change anything, please open a new issue. IMHO this issue is too long, it's better to start a fresh issue with up to date info, just mention this old issue: bpo-18747.

I have no plans to work on the issue any more. OpenSSL 1.1.1 has fixed the RNG issue with a new DRBG implementation. Eventually all platforms will move to 1.1.1 because it also provides TLS 1.3.

In the mean time, application can work around the limitation by seeding OpenSSL by calling ssl.RAND_add().