From: | dom(at)happygiraffe(dot)net (Dominic Mitchell) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | SSL Support |
Date: | 2004-09-21 07:24:52 |
Message-ID: | 20040921072452.GA67741@ppe.happygiraffe.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
ssl-doc.patch | text/plain | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-09-21 08:17:51 | Re: SSL Support |
Previous Message | Shachar Shemesh | 2004-09-21 06:55:25 | Re: No parameters support in "create user"? |