Re: [HACKERS] Should libpq set close-on-exec flag on its socket?
On Thu, Oct 21, 2004 at 02:10:48PM -0400, Tom Lane wrote: > It was suggested to me off-list that libpq should do > "fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server. > This would prevent any child program from accidentally or maliciously > interfering with the connection. It would also prevent people from > deliberately turning over a connection to a child; I'm not sure that > that's useful, but I'm not sure it's useless either. > > Comments, opinions? This is a very good idea. We've had problems with Perl programs that call other scripts (over an exec boundary) and end up with unnecessary DBD::Pg file handles hanging around. This would be good to prevent that. -Dom ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] SSL Support
Tom Lane wrote: [EMAIL PROTECTED] (Dominic Mitchell) writes: On Tue, Sep 21, 2004 at 10:17:51AM +0200, Peter Eisentraut wrote: Am Dienstag, 21. September 2004 09:24 schrieb Dominic Mitchell: 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. The code is all there to do so, pretty much. What it's missing is a few toggles to make it say "I want to enforce this to happen". This is intentional. See past discussions. Ok, I'll go and review them and stick to documentation patches. I hope I can avoid other people being surprised in the manner I was. Thanks, -Dom ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SSL Support
On Tue, Sep 21, 2004 at 10:44:22AM +0200, Kaare Rasmussen wrote: > > I think verification of the server certificates is not supported either. > > SSL only serves for encryption, not authentication or integrity checking > > (which is probably a stupid idea). > > I have this feeling that SSL in PostgreSQL isn't category 1 supported if you > can put it that way. Maybe I'm wrong? > > Another way to ensure encrypted (and authenticated, I believe) connections is > to use stunnel with PostgreSQL. > > I'm not sure which solution is the best. SSL in PostgreSQL is integrated. > Stunnel has the advantage of being more generic. having tried none, I don't > know about performance. stunnel is a possible solution, but it'll make it difficult to determine remote connections, as you'll only ever see 127.0.0.1 in your logs. As I said in my other reply, the code to do most of this is already there, it's just #ifdef'd out. -Dom ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SSL Support
On Tue, Sep 21, 2004 at 10:17:51AM +0200, Peter Eisentraut wrote: > Am Dienstag, 21. September 2004 09:24 schrieb Dominic Mitchell: > > I am also unsure of the > > procedures for submitting patches; is it ok to just send to hackers? > > [EMAIL PROTECTED] Thanks, I'll send it along there. > > 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. > > Client-side certificates as an authentication mechanism are not > intended to be supported. It might be a nice feature to add, though. The code is all there to do so, pretty much. What it's missing is a few toggles to make it say "I want to enforce this to happen". > > 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"? > > That seems reasonable. Ok, I'll knock up a patch to do so. > > 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. > > I think verification of the server certificates is not supported either. SSL > only serves for encryption, not authentication or integrity checking (which > is probably a stupid idea). > > > 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. > > This seems to match the pattern I described above. I think it's misleading to talk about SSL being supported without these options. I've used SSL in other places (apache/mod_ssl, curl, stunnel) and I came to expect this sort of verification as standard behaviour. What's more, the code is there to do it, it's just #ifdef'd out, or needs a toggle. I'm not even concerned about client certificates (though that would be useful), but just the ordinary sort of checking that goes with SSL. This is about the same level of checking that a browser would do when visiting a HTTPS site. -Dom ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] SSL Support
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 - 1.281 +++ doc/src/sgml/runtime.sgml 20 Sep 2004 20:31:24 - @@ -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. + + + If verification of client certificates is required, place the + certificates of the CA you wish to check for in + the file root.crt 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 root.crt. If no + certificate is presented, the connection will be allowed to proceed + anway. + ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
