When establishing a TLS/SSL connection somehow gets stuck there is a good chance that you are just lacking enough entropy. The tricky part is that you cannot find anything about this in the logs. If you experience similar problems, on Linux the first thing to check if there is enough entropy available.
If the number is below 1000 that might be the problem. It means that your system does not generate enough randomness for cryptographically secure communications - and waits until there is.
What is Entropy?
While the concept of randomness is a familiar concept, the distinction to entropy is less clear. The material I found from Blackhat session is not just really interesting, it also explains it in a surprisingly easy way.
- is the uncertainty of a future outcome.
- is the quality of uncertainty of historic outcomes.
Why not use PRNG?
An easy but terrible workaround is to only use a pseudo-random generator.
mv /dev/random /dev/random.old ln -s /dev/urandom /dev/random
By definition, these pseudo-random numbers cannot be really random. Mouse movements, key presses, audio or video input or disk access can be sources for proper randomness. There are dedicated daemones like haveged, egd, prngd or others that do just that. Unfortunately on a virtual server, your mileage may vary.
Cryptography algorithms rely heavily on access to high quality random numbers. They are needed for key and nonce creation. I remember a time where I was asked to move a mouse to create a good encryption key - go figure. If the bandwidth and quality of random numbers suffers, the security of the underlying can be compromised.
How bad this can be is to look at what (almost) happend at Debian in 2009. It should demonstrate very clearly how bad the “workaround” from above really is.
The impact […] is that every signature generated on a vulnerable system reveals the signer’s private key
So don’t skimp on entropy, your security my depend on it. There is enough randomness in this life - use it.