On 2006.08.31 at 14:36:28 -0400, Tom Lane wrote: > > I concur with this in the abstract: it would be better design to submit > something to the OpenSSL project to allow setting engine choices and > such site-wide. In the short term, though, it's hard to deny that our > code > > if (SSL_CTX_set_cipher_list(SSL_context, > "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH") != 1) > > is pretty ad-hoc and looks exactly like the sort of thing someone might > want to adjust. I'm willing to accept the part of the patch that makes > that string into a GUC variable, until such time as OpenSSL provides a > way to configure itself site-wide so that we can remove this code > entirely. I'm not eager to accept the other part of the patch.
OK, I'll remove ssl_engine part and add code to read global OpenSSL configuration file, so everything which can be configured in OpenSSL site-wide can be configured so in PostgreSQL backend, and cipherlist which are considered per-application in OpenSSL can be configured via postgresql.conf. I also have patch for libpq which adds following functionality 1. Read site-wide Openssl configuration file 2. Allow to specify alternate key location in the environment variable PGSSLKEY in the form <engine>:<key_id> where key_id is something engine specific. This allow to use hardware cryptographic tokens to store certificate private key. Idea is that each user has smart card or other piece of hardware and computer is equipped with appropriate reader. In order to connect to the server user inserts his token into reader. Typically such tokens (called HSM - Hardware Security Modules) never let secret key out of token. Instead they handle cryptographic operations inside the token and appropriate OpenSSL engines delegate these operations to token instead of performing them programmatically. Although interface to storage-only things such as Dallas touch memory can be implemented as OpenSSL engine module. Such setups are quite common in shops or malls. For instance, McDonalds uses such smart cards to identify which employee operates particular cash register. Current version of patch has following drawbacks 1. Certificates for all tokens must be stored on the computer (this is limitation of current OpenSSL engine API - it doesn't allow to get certificate from token) 2. Something external to libpq (i.e. application, which works as client to database) have to find out which token is inserted and put correct certificate into postgresql.crt and correct key_id into PGSSLKEY environment variable. Really, patch can be enhanced by allowing several certificates to be stored in the postgresql.crt and cycling through them until one matching specified secret key is found. What is better - send these patches (for client and for server) separately or combine them in the one patch? ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
