Thread: DH_check return value test correct?
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
Michael Fuhr <mike@fuhr.org> writes:
> Isn't that the wrong test for DH_check's return value?
Yeah, sure looks that way, doesn't it?
> 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.
So it's not that surprising that no one noticed it was broken :-(
regards, tom lane
On Fri, May 12, 2006 at 06:39:44PM -0400, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > 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. > > So it's not that surprising that no one noticed it was broken :-( Incidentally, is it necessary to load the DH parameters anew and call DH_check for every connection? The parameters don't change and DH_check is fairly expensive: checking a 1024-bit parameter on a 500MHz Pentium III takes about 260ms, which can be a significant portion of the SSL handshake. The expense is probably negligible on fast hardware but on older systems it makes connect times noticeably slow (one of my test boxes is a 143MHz sparc Ultra 1; DH_check takes almost 2 sec). -- Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
> Incidentally, is it necessary to load the DH parameters anew and
> call DH_check for every connection?
We could maybe improve on that on Unix, but not so easily on Windows.
Given the evidently nonexistent demand for this feature, I can't see
putting any work into it ;-)
regards, tom lane
On Fri, May 12, 2006 at 09:05:55PM -0400, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > Incidentally, is it necessary to load the DH parameters anew and > > call DH_check for every connection? > > We could maybe improve on that on Unix, but not so easily on Windows. > Given the evidently nonexistent demand for this feature, I can't see > putting any work into it ;-) To be honest I'm not entirely sure of the benefits of allowing people to specify the DH params. For the GnuTLS patch I just got the backend to generate the params on postmaster start because I couldn't think if a reason why you'd want to either use hard-coded values or user-specified ones. They're not security sensetive, knowing them doesn't help you crack the stream. The client simply gets a copy of the server's parameters when initiating the connection. What they do do it protect the security of the stream if the private key has been comprimised. So we should use EDH, but there's still no reason for the user to want to specify the parameters... Have a ncie day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.