[Nagiosplug-help] Lack of randomness for check_http to create TLS session keys on old AIX box

Ralph.Grothe at itdz-berlin.de Ralph.Grothe at itdz-berlin.de
Mon Dec 18 15:07:07 CET 2006


Hello Users of check_http,

I have various SSL enabled webservers whose propper TLS servicing
capabilities I need to check 
by my Nagios server.

Unfortunately I am plagued with an old AIX iron that hosts my
nagios server.

$ uname -srv
AIX 3 4

I built nagios plugins 1.4.5 on this platform with ssl enabled
where applicable
because at least an OpenSSL library was already installed here

$ ls -ld /usr/local/lib/{lib{crypto,ssl},openssl}*
-rw-r--r--   1 root     system   1579743 Oct 18 2000
/usr/local/lib/libcrypto.a
-rw-r--r--   1 root     system    369213 Oct 18 2000
/usr/local/lib/libssl.a
drwxr-sr-x   4 root     system       512 Dec 18 11:53
/usr/local/lib/openssl-0.9
drwxr-sr-x   2 root     system       512 Oct 01 2002
/usr/local/lib/openssl-0.9.6.7


$ check_http -V
check_http (nagios-plugins 1.4.5) 1.96

The admin of this AIX box must have been forced to install some
entropy gathering daemon
as a kludge to compensate for the absence of some contemporary
/dev/[u]?random devices
to persuade at least the sshd (by which I can only connect) to be
willing to create session keys,
because I can see such a beast in the proc table

$ ps -e -o uid,ppid,args|awk '$1==0&&$2==1&&$0~/egd/'
       0     1 /usr/bin/perl -w /usr/local/bin/egd.pl
/dev/entropy 

The dev arg seems to be a bit of a misnomer because it actually
looks like a Unix domain socket to me

$ ls -l /dev/entropy 
srwxrwxrwx   1 root     system         0 Apr 24 2006
/dev/entropy

Maybe it's this ill-chosen path of the egd socket that check_http
or openssl don't have on their list?

>From its perms I would gather that theoretically at least
nagios'es check_http child proc 
should be able to read the required random bits from this socket.

However, when I try to send a GET request by check_http to one of
my monitored HTTPS hosts
I get this error hinting towards a lack of randomness

$ check_http -S -I kreta
CRITICAL - Cannot make SSL connection 
60646:error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:474:
You need to read the OpenSSL FAQ,
http://www.openssl.org/support/faq.html
Error on receive

Of course, did I follow the mentioned link to the OpenSSL FAQs.
But only one short section there that deals about this without
any really helpful clues.
Instead it only mentions the useless use of the RANDFILE env var
in egd's socket context,
and that one should use the -rand switch.
But then, I am not using openssl's CLI but - as I guess the coder
of check_http did this for me -
its API instead.


<quote from="http://www.openssl.org/support/faq.html>

Pointing $RANDFILE to an Entropy Gathering Daemon socket does not
work. Use the "-rand" option of the OpenSSL command line tools
instead. The $RANDFILE environment variable and $HOME/.rnd are
only used by the OpenSSL command line tools. Applications using
the OpenSSL library provide their own configuration options to
specify the entropy source, please check out the documentation
coming the with application.

</quote>


At OpenSSL's website I also found this page that tells what an
API programmer should call
in its application code.

http://www.openssl.org/docs/crypto/RAND_egd.html


But in the sources that I have got I cannot find a call to any
*egd* function

$ grep -c egd check_http.c
0

nor any external definitions, as it seems

$ grep \#include check_http.c
#include "common.h"
#include "netutils.h"
#include "utils.h"
#include "regex.h"

but nevertheless, my binary is linked against libcrypto as well
as libssl

$ ldd check_http
/usr/local/lib/libcrypto.a(libcrypto.so)
/usr/local/lib/libssl.a(libssl.so)
/usr/lib/libc.a(pse.o)
/usr/lib/libtli.a(shr.o)
/usr/lib/libpthreads.a(shr_comm.o)
/usr/lib/libpthreads.a(shr.o)
/usr/lib/libpthreads_compat.a(shr.o)
/usr/lib/libnsl.a(shr.o)
check_http
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libc.a(shr.o)


Please, can someone give me a hint what to do
to notify check_http of the existence of that /dev/entropy
socket?


Regards

Ralph




More information about the Help mailing list