Обсуждение: Re: [PATCHES] Backend SSL configuration enhancement
"Victor B. Wagner" <vitus@cryptocom.ru> writes:
> This patch adds two new configuration diretives to postgresql.conf file
> 1. ssl_ciphers - allows server administrator to specify set of SSL
> ciphersuites which can be used by clients to connect the server.
> 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware
> crypto accelerator support) to use.
Why are either of these useful? What are the compatibility implications
of changing them? Does the addition of the engine-load code break
compatibility with older OpenSSL releases?
regards, tom lane
Tom Lane wrote: > "Victor B. Wagner" <vitus@cryptocom.ru> writes: > >> This patch adds two new configuration diretives to postgresql.conf file >> 1. ssl_ciphers - allows server administrator to specify set of SSL >> ciphersuites which can be used by clients to connect the server. >> 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware >> crypto accelerator support) to use. >> > > Why are either of these useful? What are the compatibility implications > of changing them? Does the addition of the engine-load code break > compatibility with older OpenSSL releases? > > > Is it just me, or are we seeing more patches lately that have been undiscussed? cheers andrew
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? > 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? -- Peter Eisentraut http://developer.postgresql.org/~petere/
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.
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? this is btw. something that is available in most daemons utilizing openssl - one can disable weak ciphers (which might not even be known as weak at the time the defaults where set) or ciphers not authorized for certain usage scenarios by this means. Stefan
"Victor B. Wagner" <vitus@cryptocom.ru> writes: > 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. I'm not sure that's a particularly good use case. There are attacks in the wild that hijack existing TCP connections. If you only authenticate connections and then even with the MAC checks I think you would have a chance of being able to take over the connection. That said it doesn't mean there aren't valid use cases. If for example you wanted to do some initial data load without encryption but didn't want to have to reconfigure your network to allow connections on different ports. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On 2006.08.31 at 08:52:08 +0100, Gregory Stark wrote: > > "Victor B. Wagner" <vitus@cryptocom.ru> writes: > > > 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. > > I'm not sure that's a particularly good use case. There are attacks in the > wild that hijack existing TCP connections. If you only authenticate > connections and then even with the MAC checks I think you would have a chance > of being able to take over the connection. If you are hijacking TCP connection, you have no way to get shared secret, negotiated between client and server during SSL handshake. So, you have no way to generate correct MAC. > That said it doesn't mean there aren't valid use cases. If for example you > wanted to do some initial data load without encryption but didn't want to have > to reconfigure your network to allow connections on different ports. This is not a case for PostgreSQL, which uses same port for SSL and non-SSL connection. Initial handshake with client certificates is much stronger point when comparing SSL with NULL ciphers with non-SSL connection. Also, SSL, even without client certificates, guarantees that you are connecting to the right server. So, using SSL with NULL cipher at least prevents clients from getting wrong data from malicious server due to DNS spoofing attack. Although I don't think that it is widespread attack scenario. Point made by Stefan is much better - it is very probably that somewhen in the future vulnerability in the some cipher would be discovered. If cipher list is configurable, DBA would be able to quickly fix the problem by editing configuration file, instead of recompiling PostgreSQL or OpenSSL. If this is mathematical vulnerability in the algorithm, rather than implementation bug, there would be even no need to upgrade OpenSSL. All that OpenSSL developers can do - mark this cipher as weak according to newly discovered strength. Note that current PostgreSQL cipherlist already contains such a hack: It contains !MD5 element, because MD5 digest algorithm was broken about year ago, and PostgreSQL expected to work with versions of OpenSSL which still consider it strong.
Am Donnerstag, 31. August 2006 11:29 schrieb Stefan Kaltenbrunner: > this is btw. something that is available in most daemons utilizing > openssl - one can disable weak ciphers (which might not even be known as > weak at the time the defaults where set) or ciphers not authorized for > certain usage scenarios by this means. In that case I'd expect to edit some central openssl configuration file to turn off the offending methods in one central place. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On 2006.08.31 at 10:34:02 +0200, Peter Eisentraut wrote: > Am Donnerstag, 31. August 2006 11:29 schrieb Stefan Kaltenbrunner: > > this is btw. something that is available in most daemons utilizing > > openssl - one can disable weak ciphers (which might not even be known as > > weak at the time the defaults where set) or ciphers not authorized for > > certain usage scenarios by this means. > > In that case I'd expect to edit some central openssl configuration file to > turn off the offending methods in one central place. There is no such functionality in OpenSSL configuration file. Moreover, other SSL applications such as Apache, use more fine-grained apporoach - use different ciphersuite settings for virtual hosts and even particular web pages. Cipher strength is quantitive characteristic. In some cases same cipher can be strong enough, and in some - not. I can imagine scenarios where different databases or even different roles in the same database would require different strength of cipher. For example, user with read-only access to tables (say web server, visualizing data) can connect without encryption at all, user with update/insert permissions - with 128-bit encryption, and database superuser - only with 256-bit. But I don't think that implementation of such flexibility would be neccessary until there would be certificate based database authentication.
Peter Eisentraut <peter_e@gmx.net> writes:
> In that case I'd expect to edit some central openssl configuration file to
> turn off the offending methods in one central place.
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.
regards, tom lane
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?
On Thu, Aug 31, 2006 at 12:11:46 +0400, "Victor B. Wagner" <vitus@cryptocom.ru> wrote: > > It contains !MD5 element, because MD5 digest algorithm was broken about > year ago, and PostgreSQL expected to work with versions of OpenSSL which > still consider it strong. MD5 wasn't completely broken and I believe it is still considered safe for the way it is used in SSL. It looks like SHA-1 is pretty much in the same boat now. (See http://www.heise-security.co.uk/news/77244)