From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DH_check return value test correct? |
Date: | 2006-05-13 01:02:26 |
Message-ID: | 20060513010226.GA7806@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 12, 2006 at 06:39:44PM -0400, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-13 01:03:17 | Re: audit table containing Select statements submitted |
Previous Message | Bruce Momjian | 2006-05-13 00:38:07 | Re: [GENERAL] Querying libpq compile time options |