What are the consequences (and potential mitigation) to poor entropy/RNG on server-side during ephemermal key generation and DH exchange I am using a hardware TRNG feeding the entropy pool on the client side. But, in a world of virtualized, headless server hosts, what are the cryptographic/security consequences for random numbers (or a RNG) of possibly poor quality (entropy) being used on the server side of ephemeral key generation and DH key exchange? Are there any mitigation strategies from the client side when server side operation is out of client's control?
In the worst case the result is key pair known to the attacker, in which case an attacker can act as a man-in-the-middle or eavesdrop, leaving you with no security whatsoever. There is nothing the client can do about that; even if his own key pair is fully random then the DH calculations can still be replayed by the attacker.

There is not all that much that a client can do other than to check if the public key received from the server hasn't been send yet. You could store all the public keys and compare new public keys them with previous values. This would catch repeating public keys; if one is found then stop the protocol: the server is insecure.

Fully testing the strength of the server-side RNG is very likely out of reach.



Note that with the advance of hardware-based RNGs the best mitigation against this can be done server side: use RDRAND. This is a user-level instruction that should be available from client VM's. If not used directly it can at least be used to put additional entropy in the randomness pool.

AMD uses the same instruction in their newer chips. The T1 systems from Sun/Oracle also have a hardware RNG. VIA uses a different mechanism (I/O based instructions) but with similar functionality. This kind of random number generation should be very high on your wish list for headless machines.

It could be that VM's also have some ways of mitigating risks (plugging entropy from the host system into the client VM), but I'm no VM expert.