SSL Support
От | dom@happygiraffe.net (Dominic Mitchell) |
---|---|
Тема | SSL Support |
Дата | |
Msg-id | 20040921072452.GA67741@ppe.happygiraffe.net обсуждение исходный текст |
Ответы |
Re: SSL Support
Re: SSL Support |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: