From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | DH_check return value test correct? |
Date: | 2006-05-12 17:19:40 |
Message-ID: | 20060512171940.GA91542@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
load_dh_file() in src/backend/libpq/be-secure.c does the following:
if (DH_check(dh, &codes))
{
elog(LOG, "DH_check error (%s): %s", fnbuf, SSLerrmessage());
return NULL;
}
Isn't that the wrong test for DH_check's return value? According
to the OpenSSL documentation "DH_check() returns 1 if the check
could be performed, 0 otherwise."
http://www.openssl.org/docs/crypto/DH_generate_parameters.html
That is, if the return value is 1 then the caller can proceed with
tests for DH_CHECK_P_NOT_PRIME, etc., but if the return value is 0
then DH_check failed for some reason. The DH_check source code
appears to confirm this interpretation.
http://cvs.openssl.org/getfile/openssl/crypto/dh/dh_check.c?v=1.8
The DH_check test in load_dh_file() is reached only if the DBA has
generated DH parameters and installed them in $PGDATA. You can do
that with
openssl dhparam -out $PGDATA/dh1024.pem 1024
(This command can take several minutes to run.)
If $PGDATA/dh1024.pem exists and if SSL connections are enabled,
then each SSL connection logs the following:
DH_check error (dh1024.pem): No SSL error reported
The backend then loads the hardcoded parameters. The SSL connection
works, but with DH parameters other than intended.
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-05-12 17:32:30 | Re: audit table containing Select statements submitted |
Previous Message | Hogan, James F. Jr. | 2006-05-12 17:11:14 | audit table containing Select statements submitted |