From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | dom(at)happygiraffe(dot)net (Dominic Mitchell) |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSL Support |
Date: | 2004-09-26 23:09:20 |
Message-ID: | 12606.1096240160@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
dom(at)happygiraffe(dot)net (Dominic Mitchell) writes:
> I've just spent a while this afternoon attempting to get SSL support
> working. It appears to be lacking in a few areas, foremost
> documentation.
After reviewing this stuff, it's clear that there were some things that
were supposed to work but were broken. The agreement that we'd come to
about SSL support, as I understood it, was that we'd not *require*
client certificates to be present and validatable, so that it would be
possible to use SSL in an encryption-but-not-authentication fashion.
However there was never any intention to *prevent* use of the
authentication features. Unfortunately it seems a lot of bit rot
has snuck in, and I'm not sure some of the bugs weren't there all along
(the original SSL patch had a lot of problems :-().
I've committed a patch that gets it up to minimum functionality, ie,
the server and client do seem to both detect bogus certificates on the
other end when they have root.crt files to work from. I'm no SSL expert
though, so it could be there's still work to be done.
> In initialize_SSL(), we call SSL_CTX_set_verify(), but we don't pass
> in the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag.
Seems to have been put on the wrong set_verify call :-(. Fixed.
> In initialize_SSL(), we call SSL_CTX_set_verify_depth(SSL_context, 1).
> This should probably be a configurable item.
I can't see a reason to have it at all, especially when there is no
corresponding limitation on the server side. Removed.
> In open_client_SSL(), the call to SSL_get_verify_result() is commented
> out. This means that crucial things such as the validity of the
> certificate of the server you are connecting to is not checked. So
> the client will happily connect to an expired certificate.
Not in my testing ... it could be we should also uncomment that, but
I'm unconvinced that it's needed.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Koju Iijima | 2004-09-26 23:39:06 | patch for temporary view from TODO list |
Previous Message | Andrew Dunstan | 2004-09-26 19:00:00 | Re: [HACKERS] cvsup |