Re: [PATCHES] Backend SSL configuration enhancement

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.

"Victor B. Wagner" <vitus(at)cryptocom(dot)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(at)cryptocom(dot)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

On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote:

> "Victor B. Wagner" <vitus(at)cryptocom(dot)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

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.

It might be requirement of enhanced security, or some national standards requirement.

Or vice versa - people might want client certificates for
authentication, but avoid encryption for performance reasons.

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,
i.e. national standards, which are not supported in the OpenSSL core.

We have developed this patch in order to use Russian GOST algorithms
for SSL connections.
> of changing them? Does the addition of the engine-load code break
> compatibility with older OpenSSL releases?

Engines have appeared in OpenSSL quite a long ago. Version 0.9.7 already
supports them. So, compatibility is broken only with 0.9.6 and eariler
which have numerous other problems anyway.

I can recheck my patch and add conditional compilation around engine
loading code to be sure that it doesn't break compatiblity with 0.9.6,
just ignores ssl_engine keyword if underlying OpenSSL doesn't support
engines.

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.

"Victor B. Wagner" <vitus(at)cryptocom(dot)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(at)cryptocom(dot)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 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

Peter Eisentraut <peter_e(at)gmx(dot)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(at)cryptocom(dot)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)

This has been saved for the 8.3 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Victor B. Wagner wrote:
> On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote:
>
> > "Victor B. Wagner" <vitus(at)cryptocom(dot)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
>
> 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.
>
> It might be requirement of enhanced security, or some national standards requirement.
>
> Or vice versa - people might want client certificates for
> authentication, but avoid encryption for performance reasons.
>
> 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,
> i.e. national standards, which are not supported in the OpenSSL core.
>
> We have developed this patch in order to use Russian GOST algorithms
> for SSL connections.
> > of changing them? Does the addition of the engine-load code break
> > compatibility with older OpenSSL releases?
>
> Engines have appeared in OpenSSL quite a long ago. Version 0.9.7 already
> supports them. So, compatibility is broken only with 0.9.6 and eariler
> which have numerous other problems anyway.
>
> I can recheck my patch and add conditional compilation around engine
> loading code to be sure that it doesn't break compatiblity with 0.9.6,
> just ignores ssl_engine keyword if underlying OpenSSL doesn't support
> engines.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> This has been saved for the 8.3 release:
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold

This version was withdrawn by the author for rework, no?

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > This has been saved for the 8.3 release:
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> This version was withdrawn by the author for rework, no?

Right, and the thread in patches_hold shows that. The reason it is in
there is so we can ping the author at the start of 8.3 to get an updated
version.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote:

> Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > This has been saved for the 8.3 release:
> > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >
> > This version was withdrawn by the author for rework, no?
>
> Right, and the thread in patches_hold shows that. The reason it is in
> there is so we can ping the author at the start of 8.3 to get an updated
> version.

I've already send version 2 of the patch to patches mailing list.
I think that this letter even got into thread mentioned above.

It's a pity that it's to late for patch to get into 8.2.
It means that during all 8.2 lifecycle we'll have to maintain this patch
separately.

Victor Wagner wrote:
> On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > > This has been saved for the 8.3 release:
> > > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> > >
> > > This version was withdrawn by the author for rework, no?
> >
> > Right, and the thread in patches_hold shows that. The reason it is in
> > there is so we can ping the author at the start of 8.3 to get an updated
> > version.
>
> I've already send version 2 of the patch to patches mailing list.
> I think that this letter even got into thread mentioned above.
>
> It's a pity that it's to late for patch to get into 8.2.
> It means that during all 8.2 lifecycle we'll have to maintain this patch
> separately.

Yep, sorry.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Sep 05, 2006 at 10:17:15AM +0400, Victor Wagner wrote:
> It's a pity that it's to late for patch to get into 8.2.
> It means that during all 8.2 lifecycle we'll have to maintain this patch
> separately.

Hmm? After 8.2 releases, if it's ready, it will go straight into CVS at
which point it'll be in the next release.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.