> openssl-0.9.6b does not allow ssl/tls connections when the random number
> has not been seeded. This is a good idea, and it exposes that the
> starttls patch for qmail does not seed the random number generator.
>
> Here is a small patch that fixes the problem in qmail-remote for systems
> that support /dev/urandom (the same can be done for qmail-smtpd but I
> can't test it right now). Not seeding the random number generator is a
> serious bug and it completely compromises the cryptographic privacy of
> TLS encrypted emails.
Not seeding the PRNG is a serious error. However OpenSSL should
seed from /dev/urandom automatically without even calling RAND_seed:
OpenSSL makes sure that the PRNG state is unique for each
thread. On systems that provide /dev/urandom, the
randomness device is used to seed the PRNG transparently.
However, on all other systems, the application is
responsible for seeding the PRNG by calling RAND_add(),
RAND_egd(3) or RAND_load_file(3).
So the question becomes *why* is in not seeding from /dev/urandom
on it's own? Also you should make sure to check the return values
in your code -- on systems with no /dev/urandom you will seed with
32-64 bytes of non-random data instead, giving the appearance of
security where this is none.
You may want to check out the RAND_egd() function which can be used
to seed from a PRNG daemon. If you want to look at some rather long
winded but thougrough PRNG-seeding code, see the initialize_prng
function (in ssl.c) in the Stunnel source code.
--
Brian Hatch Linux is like wigwam -
Systems and no windows, no gates,
Security Engineer apache inside.
www.hackinglinuxexposed.com
Every message PGP signed
PGP signature
