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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
