Re: [PATCHES] Backend SSL configuration enhancement

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?