Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-07 Thread Victor Wagner
On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote:

 Tom Lane wrote:
  Bruce Momjian [EMAIL PROTECTED] 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.


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-07 Thread Martijn van Oosterhout
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@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-05 Thread Bruce Momjian
Victor Wagner wrote:
 On 2006.09.04 at 15:46:03 -0400, Bruce Momjian wrote:
 
  Tom Lane wrote:
   Bruce Momjian [EMAIL PROTECTED] 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   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

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

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-04 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-04 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] 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   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-09-01 Thread Bruno Wolff III
On Thu, Aug 31, 2006 at 12:11:46 +0400,
  Victor B. Wagner [EMAIL PROTECTED] 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)


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Victor B. Wagner
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


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Stefan Kaltenbrunner

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

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Gregory Stark

Victor B. Wagner [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Victor B. Wagner
On 2006.08.31 at 08:52:08 +0100, Gregory Stark wrote:

 
 Victor B. Wagner [EMAIL PROTECTED] 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.



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Peter Eisentraut
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/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Victor B. Wagner
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.


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-31 Thread Victor B. Wagner
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?



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-30 Thread Tom Lane
Victor B. Wagner [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-30 Thread Andrew Dunstan

Tom Lane wrote:

Victor B. Wagner [EMAIL PROTECTED] 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


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Backend SSL configuration enhancement

2006-08-30 Thread Peter Eisentraut
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/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org