The attacker doesn't have the TLS private key, they have the RNG key. But they don't have the RNG seed. Recovering the seed is necessary to predict other RNG outputs and break TLS, but requires observing more RNG output than one typically sees.
FWIW, the operative theory here is that "Extended Random" was designed to work in concert with the DUAL_EC DBRG/RNG, which almost certainly allows "Clyde Frog" to predict all future output on the basis of very few samples.
"Using that private key, they can observe CSPRNG output on the wire, “decrypt it”, and use that to rewind and fast-forward other people’s CSPRNGs, discovering their keys."
If the victim is using Dual_EC_DRBG and Clyde Frog can obtain ~32 bytes of RNG output, they can figure out in reasonable time what the seed to the RNG was (assuming they know how the curve parameters were generated).
"This is a huge deal in the case of SSL/TLS, for example. If I use the Dual-EC PRG to generate the "Client Random" nonce transmitted in the beginning of an SSL connection, then the NSA (sic) will be able to predict the "Pre-Master" secret that I'm going to generate during the RSA handshake. Given this information the connection is now a cleartext read. "[1]
So, Clyde Frog can figure out your RNG state and predict what key you will generate for your TLS session. That's how they obtain the private key.
Indeed. So the issue here is to deduce the symetric keys generated with a Cryptographically Secure Psoeudo Random Function (CSPRF) seeded with information exchanged during the initiating handshake and using the respective public and prvate keys, without having any private keys.
Imagine now that with a handfull pseudo random bytes sent in clear with the TLS protcol an eavesdropper could deduce the internal state of the CSPRF and thus the symmetric keys. They could decrypt the channel.