Re: [PATCHES] Backend SSL configuration enhancement

On 2006.08.31 at 00:09:56 +0200, Peter Eisentraut wrote:

> Victor B. Wagner wrote:
> > First one is useful if for some reason some ciphers supported by
> > OpenSSL is not permitted to use in the particular network, or if
> > there is need to use ciphersuites which are not included into default
> > ciphersuite list, now compiled into PostgreSQL.
> 
> Do you have specific examples where that might be the case?


One example which can be tested with stock OpenSSL without national
cryptography modules is - usage of NULL ciphers. They are not enabled by
default, but use of them provides cryptographically strong
authentication with client certificates and data consistency checking
with MAC algorithm, but avoids overhead of encryption.

Consider situation when data are public anyway, but data modification
should be properly authorized. 



> > Second one can be used for taking cryptography load from server into
> > special hardware chip, which can be useful for loaded servers.
> > Also, upcoming OpenSSL 0.9.9 allows to add entirely new cryptographic
> > algorithms via engines, so engine support allows to use algorithms,
> 
> ISTM that that should be in a system-wide OpenSSL configuration, not to 
> be hacked into each SSL-using application separately.  Is that 
> possible?

Really this is possible. Just make PostgreSQL call OPENSSL_config(NULL).
This function reads default OpenSSL configuration file and perform
neccessary initialization. Note that OpenSSL authors haven't put this
code into SSL_library_init, but provide additional API function instead.

We take this approach in our libpq patch (which is not submitted yet). 

But we choose another approach for backend patch.

Reason is that database server is more-or-less self-contained thing, and
may need another cryptography configuration then end-user applications or 
other servers running on the same machine. It even can be that they
are administered by different people. So, we think that it is better to
have all server configuration in the same place, and avoid dependencies 
on system-wide library configuration.

Really, it is possible to have separate OpenSSL configuration files for
different applications, and use environment variable to point to correct
one. PostgreSQL server typically run as special user, and in most cases
there are special provisions to set up specific environment for backend.

So, goal of ssl_engine configuration directive can be possibly achieved
by simplier patch, which just calls OpenSSL function to read
configuration file. But, to make things clear for DBA, we should
write a section in administration guide which describe consequences of
reading system-wide openssl.cnf, ways to find default location of this
file, and method of specifing location of alternate openssl
configuration file, if it is required.