Thread: DH_check return value test correct?

DH_check return value test correct?

From
Michael Fuhr
Date:
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


Re: DH_check return value test correct?

From
Tom Lane
Date:
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


Re: DH_check return value test correct?

From
Michael Fuhr
Date:
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


Re: DH_check return value test correct?

From
Tom Lane
Date:
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


Re: DH_check return value test correct?

From
Martijn van Oosterhout
Date:
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.