Hi Bill,
> I thought the build and test environments were just "supposed to work". It
> seems to me that they should. If nothing else, you might consider
> distributing OpenSSL with sample random data for the purpose of testing.
> Putting some junk in the RANDFILE file worked just fine, though - you were
> right.
But then the self-test is not alerting you to an "error" about the host
environment that it *should* alert you to!
OpenSSL is a programming toolkit for writing applications that can
(amongst other possibilities) have SSL functionality. It is not an
application, although a pretty handy little application (plus tests and
other assorted goodies) does come bundled. Quizzing the host environment
for "settings" is really not the domain of the toolkit, nor should it be.
If you are not aware already, perhaps you should note that many of the
cryptographic primitives in OpenSSL, and many of the component operations
used in the SSL and TLS protocols require high quality entropy. Failing to
have high quality entropy will not manifest itself as an "error", it will
simply manifest itself as a functioning application that everyone will
think is secure except those you wish to protect your data from. OpenSSL
was deliberately altered to complain like hell if it isn't fed some
(assumed to be good quality) entropy from the calling application and it
can't automatically find some in common locations. (Yes, some degree of
probing the environment to save the caller from providing everything was
done to make 99% of the inconvenience and RTFMs go away). Forcing
application programmers (or system admins and the like who might wish to
use the bundled utilities directly) to address this issue is better than
letting far less users and programmers encounter errors for the price of
having them all creating and running essentially insecure software.
Now I take your point about it perhaps being preferable that the test
utilities already have some sample junked-together random data. However,
people use the source code to the tests as examples of how to do things -
some even reuse large chunks of the code as-is with minor modifications
where necessary. Running the tests also provide examples of how things
should work on the host-system. Most of all, running the tests on systems
that don't have any kind of reliable source of randomness in the common
locations, *should* highlight this fact! Lack of available randomness is
as much an error as far as the programmer/user is concerned as a broken
DSA implementation would be. The difference is simply whether there's a
bug in the OpenSSL source code, or whether there's a problem in the
programmer's/user's environment - either way there's a problem. Your error
stack illustrated which of those the problem was.
If anyone thinks that having the build and self-test run through cleanly
will somehow allow people to build more secure systems or software, even
in spite of glaring problems on the host-system that *should* be brought
to their attention, then they need to read Bruce Schneier's book.
> The reason I didn't do that to begin with was because RANDFILE was not set
> when I tried to build the first time. The error message said:
>
> Consider setting the RANDFILE environment variable to point at a file that
> 'random' data can be kept in (the file will be overwritten).
>
> I did that. I created a file that random data could be stored in and
> pointed RANDFILE to it. The message dind't say "set RANDFILE to point to a
> file that already has random data in it, and rest assured that your random
> data will not be damaged." Had it said that, I might have known to point it
> to a message log or something. I certainly took "that random data can be
> kept in (the file will be overwritten)" to mean that OpenSSL would generate
> its own random data and store it in that file.
Please read up a little bit on PRNGs, and why they are important in
cryptography. Providing an empty file to write to does not solve a
PRNG-seeding shortage. The point about the file being overwritten is
simply that as time passes, OpenSSL's PRNG code will be "stirring" the
entropy pool and will save that out to the same file - otherwise everytime
you start the software with the same file, you'll have the same PRNG
state! Please also try to understand that OpenSSL exists to provide tried
and tested cryptographic code, not to save everyone out there from having
to think very directly about what it takes to write strong (hopefully)
secure software. I don't suggest that to you to try and cut down on the
number of questions posted to openssl-users (which is where this really
should be taking place rather than openssl-dev), but as a favour to you
and anyone using the software or systems you are creating. Netscape's
failure to pay due attention to this very same subject resulted in a
browser that was far more insecure than the algorithms its cryptographic
library implemented - yet it "appeared" to be functioning just fine. If
Netscape can have that problem, then so can you - and the world's best DSA
implementation is not going to help you if you feed it predictable
"random" data. The self-test pointed out to you that it, like any source
code you might have subsequently written, has a PRNG problem you really
need to think about. The test did its job, both testing the environment as
well as the source code.
As the front-end to the system that will incorporate OpenSSL, you (as an
application programmer, system administrator, or whatever) are the one who
should be enlightening the OpenSSL API as to how and from where it should
accumulate random input data. The ways and means of doing that will vary
wildly from system to system, and even then may be better handled in
different ways depending on the application and other circumstances in
which it's being used. On many commonly deployed (and less specialised)
systems, OpenSSL's built-in "I'd might as well try 'here' before
complaining about PRNG seeing" handling will save some people from having
to think too hard about this - although there's plenty of other ways to
botch your own security up that OpenSSL will never stop you doing, so it's
better not to get too complacent. I'm sure there are probably some people
who still think the auto-seeding is a bad idea and that *everyone* should
have to explicitly seed the PRNG, and they'd have a good argument. If I
could somehow sucker your application (or its source code) to read
/dev/zero rather than /dev/urandom without you noticing, then I'd have a
very good chance of predicting your entire PRNG state and guessing your
sessions keys (for example) even though you'd probably think your
application is running fine. Forcing programmers and administrators who
are running the "interface" to OpenSSL to explicitly address the issue of
where randomness is gathered from helps to close these invisible but fatal
security holes.
> If you can't make the distribution build and test successfully out-of-box,
> it might be helpful to at least change these instructions so that us
> dingbats can figure out what the correct solution is without polluting the
> Listserver with this trivial stuff.
It's in the FAQ. And I again think it is well-advised that anyone wanting
to write applications containing cryptography read up on these type of
issues rather than hoping libraries such as this will make the problem
just disappear. Your applications will not be secure at all, they will
just present the illusion that they are, which is far more irresponsible
than doing nothing at all. OpenSSL can not and should not try to address
all these environment issues on your behalf. The built in utilities and
tests that come with the library know as much about the end-users
environment as the library source code itself does - which is to say -
very little. If the tests don't alert you to that kind of issue, then how
good a test is it from a practical point of view?
> Once I fed the PRNG, however, the tests ran fine.
Yes, and the test - like any application you write and use in the same
way, will be no more secure than the unpredictability of the seeding you
gave it.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
