Thread: Porting issue with openssl and no /dev/random
I installed the client part of postgres on a Compaq Alpha running tru64
Unix 4 (or what they are calling it these days) using the openssl library.
This machine does not have random device and openssl's library insists
on some random data in order to start up. This prevented me from running
the software as downloaded. I made some changes to fe-connect.c to
read ~/.rnd for initial state so I could use the feature.
This isn't exactly a postgres problem, but it may be that you can check
for this case (no /dev/random and openssl) and call the ssl functions
to get random state from a file.
I am including the diff of changes I made to get this to work, though
it isn't a robust solution.
*** fe-connect.c Sat Mar 31 17:14:37 2001
--- /home/bruno/fe-connect.c Thu Oct 25 15:14:24 2001
***************
*** 48,53 ****
--- 48,57 ----
#include "mb/pg_wchar.h"
#endif
+ #ifdef USE_SSL
+ #include "openssl/rand.h"
+ #endif
+
#ifdef WIN32
static int
inet_aton(const char *cp, struct in_addr * inp)
***************
*** 792,797 ****
--- 796,802 ----
#ifdef USE_SSL
StartupPacket np; /* Used to negotiate SSL connection */
char SSLok;
+ char randfile[1000];
#endif
***************
*** 986,991 ****
--- 991,1001 ----
{
SSL_load_error_strings();
SSL_library_init();
+ if (RAND_file_name(&randfile, sizeof randfile)) {
+ if (RAND_load_file(&randfile, 1024) > 0) {
+ RAND_write_file(&randfile);
+ }
+ }
SSL_context = SSL_CTX_new(SSLv23_method());
if (!SSL_context)
{
Bruno Wolff III <bruno@cerberus.csd.uwm.edu> writes:
> I installed the client part of postgres on a Compaq Alpha running tru64
> Unix 4 (or what they are calling it these days) using the openssl library.
> This machine does not have random device and openssl's library insists
> on some random data in order to start up. This prevented me from running
> the software as downloaded. I made some changes to fe-connect.c to
> read ~/.rnd for initial state so I could use the feature.
> This isn't exactly a postgres problem, but it may be that you can check
> for this case (no /dev/random and openssl) and call the ssl functions
> to get random state from a file.
I believe we discussed this awhile back and decided that it wasn't a
good idea for Postgres to hack around what is really an OpenSSL bug.
IIRC, the problem was supposed to be fixed in an upcoming OpenSSL
release; do you have the latest openssl?
regards, tom lane
Bruno Wolff III <bruno@cerberus.csd.uwm.edu> writes:
> It looks like they consider not running without seeding the PRNG a feature
> and that this isn't something likely to change soon.
One man's feature is another man's bug, I'd say. How can they consider
it a good decision to leave it to the application to solve this problem?
Especially when they *do* solve the seeding problem on some platforms?
Their stance is completely inconsistent. If they're concerned about
preventing use of predictable seeds, the last thing they should want to
do is allow a surrounding application to apply a sloppy solution (like
the constant seed you just suggested). They should think of the best
solution they can, and embody it in their library. There is *no* chance
that an application developer is going to invent a better way on the
spur of the moment, and every chance that he'll blow a mile-wide hole
in the security of their library.
Grumble.
regards, tom lane
Bruno Wolff III <bruno@cerberus.csd.uwm.edu> writes:
> In some sense the real problem is that tru64 unix doesn't have a /dev/random
> device. This should really be a standard feature in all unix like systems.
Yeah. I suspect the real subtext here is that the openssl people would
like to see such systems go away, or else force people to run
substitutes for /dev/random (egd for example). They can't quite muster
the political gumption to say "you MUST run egd" to users, however,
and the result is that application authors are invited to supply
half-baked kluges to fill the gap.
> Maybe a note could get tacked on to the INSTALL information for enabling
> ssl to warn people that there might be issues if they are using openssl
> and their system doesn't have a /dev/random device?
If you didn't read openssl's own warnings to that effect, you probably
won't notice Postgres' either ;-)
regards, tom lane
On Mon, Oct 29, 2001 at 04:14:20PM -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I believe we discussed this awhile back and decided that it wasn't a > good idea for Postgres to hack around what is really an OpenSSL bug. > IIRC, the problem was supposed to be fixed in an upcoming OpenSSL > release; do you have the latest openssl? On the particular machine without /dev/random we have openssl-engine-0.9.6a installed. I looked at the change logs for 0.9.6b and didn't see a change that would change how it works in this case. I also checked the latest snapshots for the upcoming 0.9.7 release and things appear to be the same there. (They will be adding an automatic check for EGD, so that might cover a larger set of systems.) The following is from the 0.9.6b documentation: OpenSSL makes sure that the PRNG state is unique for each thread. On systems that provide C</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(), L<RAND_egd(3)|RAND_egd(3)> or L<RAND_load_file(3)|RAND_load_file(3)>. It looks like they consider not running without seeding the PRNG a feature and that this isn't something likely to change soon. If you want to override their decision, I think the simplest solution is to call RAND_seed with some (not necessarily random) data. That should be pretty portable. Their FAQ says only 128 bits of entropy are needed to pass the seed check.
On Tue, Oct 30, 2001 at 10:13:27AM -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruno Wolff III <bruno@cerberus.csd.uwm.edu> writes: > > It looks like they consider not running without seeding the PRNG a feature > > and that this isn't something likely to change soon. > > One man's feature is another man's bug, I'd say. How can they consider > it a good decision to leave it to the application to solve this problem? > Especially when they *do* solve the seeding problem on some platforms? > Their stance is completely inconsistent. If they're concerned about > preventing use of predictable seeds, the last thing they should want to > do is allow a surrounding application to apply a sloppy solution (like > the constant seed you just suggested). They should think of the best > solution they can, and embody it in their library. There is *no* chance > that an application developer is going to invent a better way on the > spur of the moment, and every chance that he'll blow a mile-wide hole > in the security of their library. In some sense the real problem is that tru64 unix doesn't have a /dev/random device. This should really be a standard feature in all unix like systems. I can see from your point of view that their library is broken. It would probably make the most sense to pick some initialization method(s) when building openssl rather than using a platform independent list to try out at run time. Maybe a note could get tacked on to the INSTALL information for enabling ssl to warn people that there might be issues if they are using openssl and their system doesn't have a /dev/random device?