| 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: | Whole Thread | Raw Message | 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 |