Yes, there is a risk here, though it is almost entirely limited in scope to the network/users of such proxy/firewall devices. Low entropy could also have a very minor effect on the client nonce in the TLS handshake impacting outbound connections from the proxy/firewall device.
Low entropy might mean guessable primes, which means guessable private keys, which can lead to viable MITM attacks. If there's a low-entropy issue on such a system, and the CA key is the first thing generated, then you might have a real problem.
(There's an obvious beartrap with such systems if using a shared or vendor provided key/CA, but that's quite a different problem.)
Greater risk is generally assigned to issues of proper chain and revocation verification, and poor configuration leading to the use of insecure legacy SSL or ciphers, see US CERT TA17-075A HTTPS Interception Weakens TLS Security (to this I would add insufficient protection of private keys, at least one commercial product supports HSMs, though I suspect that only works for the internal CA rather than the on-demand certificates).
The potential issue here is that if the entropy is low, the primes may be predictable — but this alone doesn't make the modulus easier to factorise (to determine the private key). It does make a brute force attack viable, in this case brute forcing PRNG input (the attacker knows the PRNG) to attempt to discover a prime (and hence key) that's in use.
If you happen to be an evil administrator with access to such a proxy that you can harvest keys and certificates from, then you have the deck stacked in your favour if attacking someone else's proxy.
As an evil user you might be able to generate enough traffic to find collisions, but this is less interesting.
In practise (certainly the case with OpenSSL) a PRNG is used to generate the key source material (to search for primes), so very little "real" entropy is required. A proxy is generally a good candidate for harvesting entropy from timing and hardware events (potentially busy network and disk, with many random connections).
I estimate roughly 90-100kiB of PRNG output would generally be required for a 2048-bit key generation (2x 1024-bit primes, with a naïve generate/test/discard algorithm), requiring only a handful of non-PRNG bytes of "real" entropy to seed (32 bytes by observation). The delay in key generation is actually the primality testing.
For the implications of low-entropy keys you can read the (wittily titled) paper Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices (PDF).
There are two useful papers which discuss security issues around the use of such proxies:
These raise many other security concerns, but randomness/entropy is only referenced briefly in the second one:
Entropy during generation.
It is possible that the entropy
used during the generation of a new public/private key pair
in install-time generated certificates is inadequate. In practice,
since most products we analyzed generate a root certificate
with RSA keys using OpenSSL, the generation process is
expected to call certain known functions, e.g., RAND_seed(),
RAND_event(), RSA_generate_key_ex(); we found
calls to the last function in many cases. However, we did not
investigate further the key generation algorithm in CCAs.
See also:
