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. I've got a patch filling in the missing pieces for the
server side, but I am unsure where I should document the client side
bits (~/.postgresql/root.crt and friends). I am also unsure of the
procedures for submitting patches; is it ok to just send to hackers?
Going through the code I spotted what appear to be problems. Although
I'm not familiar with the internals and this is only a cursory glance
through the code.
* src/backend/libpq/be-secure.c
In initialize_SSL(), we call SSL_CTX_set_verify(), but we don't pass
in the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag. This means that a client
can present no certificate and still get access to the server.
There's nothing that gets logged to say that an SSL connection was
made. This would be useful for testing. Something like logging the
connection as "1.2.3.4/ssl"?
* src/interfaces/libpq/fe-secure.c
In initialize_SSL(), we call SSL_CTX_set_verify_depth(SSL_context, 1).
This should probably be a configurable item. I /think/ it might be
stopping me from successfully verifying the server certificate is
signed by the CA listed in my client's root.crt file, but I'm not
sure.
There is no ability to indicate failure to read the client root.crt.
This is because it's just magically turned on by the presence of that
file. Perhaps it should be another PQconnectdb() option?
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.
In open_client_SSL() again, the call to verify that the CN of the
certificate is the same as the hostname you've connected to is
commented out. So you have no idea whether or not you've connected to
the right server.
* [both files]
Having hard coded file names is a bit of a pain. Particularly so for
the client, as it means that two users of libpq cannot use different
certificates. I admit this is unlikely, but still. Of course, it
would be slightly better if documented.
I'm happy to have a go at fixing these problems, if that's acceptable.
Unfortunately the SSL support isn't really usable for me without them.
-Dom
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.281
diff -u -r1.281 runtime.sgml
--- doc/src/sgml/runtime.sgml 17 Sep 2004 22:40:46 -0000 1.281
+++ doc/src/sgml/runtime.sgml 20 Sep 2004 20:31:24 -0000
@@ -4353,6 +4353,17 @@
to turn the certificate into a self-signed certificate and to copy the
key and certificate to where the server will look for them.
</para>
+
+ <para>
+ If verification of client certificates is required, place the
+ certificates of the <acronym>CA</acronym> you wish to check for in
+ the file <filename>root.crt</filename> in the data directory. When
+ present, a client certificate will be requested from the client
+ making the connection and it must have been signed by one of the
+ certificates present in <filename>root.crt</filename>. If no
+ certificate is presented, the connection will be allowed to proceed
+ anway.
+ </para>
</sect1>
<sect1 id="ssh-tunnels">
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
