Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We have a secure web service running Apache that requires client certificates for access. This service has a problem with running out of entropy. We have several other sites that use TLS that get similar amounts of traffic but have never had any problem with a lack of entropy.

I am wondering if requiring a client certificate requires more entropy. Looking at the TLS specification I don't see where the client providing a certificate places more demand on the server-side entropy source. Maybe our problem has nothing to do with client certificates, but I would like to eliminate that as a problem source.

share|improve this question
add comment

1 Answer

up vote 4 down vote accepted

If you "run out of entropy", then you are using /dev/random, and you should not. You should use /dev/urandom. The whole concept of "running out of entropy" is based on a flawed metaphor in which randomness is viewed as a kind of gasoline. That's just wrong. Recent versions of the man page of /dev/random (on Linux) are less terrible than what they used to be, and now recommend the right thing, which is to use /dev/urandom.

(When I say "you" it might be "the software you use". Regardless, someone is doing a stupid thing, and that stupid thing probably involves /dev/random.)

In any case, certificate validation entails verifying digital signatures, and there is no need of any kind of randomness for that (at least with "normal" signature algorithms like RSA, DSA or ECDSA).

Edit: actually, while the basic certificate validation uses no randomness at all, the checks for revocation status entail contacting external servers to download CRL or OCSP responses, so that's network traffic which may stall and thus display symptoms similar to a blocked read on /dev/random. And the protocol to obtain an OCSP response may include a random nonce included by the requester (here, the server), so it is conceivable that a read on /dev/random still lurks in that code. That's a bit far fetched.

share|improve this answer
    
We had already moved to /dev/urandom but our security policy frowns on that for applications that are supposed to be "highly-secure". –  rlandster Feb 6 '12 at 18:48
1  
Then it's time to update your security policy, @rlandster, as Tom is exactly right that you should be using /dev/urandom, not /dev/random. –  D.W. Feb 7 '12 at 5:33
    
You might want to consider adding a RNG/PRNG source. There are expensive hardware devices for this. A cheap software-only solution that seems to work well (and is supposed to be secure) is the terribly-named HAVEGED –  Yoav Aner Feb 7 '12 at 12:28
    
@Tom - re your hypothesis on CRL/OCSP, I'm not sure but I imagine the server providing those are themselves using SSL? In that case, it's not purely network traffic, but SSL traffic. Agree this probably is quite far fetched. –  Yoav Aner Feb 7 '12 at 12:35
    
@YoavAner: ah yes, it is conceivable. I have actually seen it done (CRL publication with an https:// URL) even though it makes little sense. –  Tom Leek Feb 7 '12 at 12:50
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.