> The way you fixed the problem is not secure. It works in most cases but it
> may fail in some cases. Your patch does not check for error codes that may
> be returned by open() and if read() returns less characters than 33 your
> code just skips seeding the PRNG without returning any error.
>
> As we can read in kernel sources, open("/dev/urandom") and read() should
> not return error but you can't depend on this if you wan't to provide
> secure fix. If kernel changes your code may become insecure and would need
> to be fixed again and again...
Not to mention the fact that /dev/random on Solaris is a pipe, and thus could
(maybe) return less. Though I've never seen or used the implementation there,
so I couldn't say for sure. But generally you can't rely on the fact that
/dev/urandom is always going to give you as much as you want.
Of course this is ignoring the fact that the only time OpenSSL will seed
itself is precisely when /dev/urandom exists, so the value of this patch is
questionable (but, of course, the fact that qmail doesn't seed the RNG is a
serious error and should probably be fixed).
[from the original post by Felix von Leitner]:
> it completely compromises the cryptographic privacy of TLS encrypted
> emails.
3 points I feel I have to make here:
1) If you're depending on the fact that your mail server is TLS encrypting
your emails, you're asking for it. Even if it is encrypting everything going
out (which seems unlikely; how many mail servers out there are configured for
TLS SMTP?), more likely than not at some point it will be decrypted and sent
over the wire in plaintext. It's comparable (IMO) to using telnet, on the
assumption that the OS will be using IPSec. Use PGP or S/MIME if you want to
secure your email.
2) IIRC, OpenSSL adds a few "random" things like pid, uid, time, etc in the
creation of the key (it's possible I'm thinking about some other subsystem, so
somebody tell me if I'm wrong here). But if so, I'd imagine there are at least
25-35 bits of security in the key then. Which is of course quite poor, but it
would take at least a little while to break each session key, which (IMHO) is
more security than you should expect from this (which is precisely that given
by normal mail, none).
3) Oh, one more thing. An SSL/TLS key is negotiated between the client and
server, and derived from random values sent by each of them. So I don't think
the session keys would actually be vulnerable, unless TLS over SMTP uses some
odd variation from the normal protocol. Unless, of course, both servers were
running a qmail server that wasn't seeding the RNG. :)
Regards,
Jack
This archive was generated by hypermail 2b30 : Wed Aug 15 2001 - 11:10:59 PDT