I should have some time free... and I wanted to get back to what 
seemed to be the most critical problem in the last cycle with the 
SSL code.

Specifically, it's time to think about setting up a "policy" file. 
This puts a bit more work on the DBA, but it gives them complete 
flexibility in how their system is set up.

The policy files would need to specify the following items:


Connection parameters

1) which protocol to use (SSLv2, SSLv3, SSLv23, TLSv1)

2) which ciphers to use (e.g., DES, DES3, IDEA, AES, blowfish, 
twofish, RC2, RC4, etc.)  Use "openssl ciphers" for a list of the 
actual ciphers supported in your version of openssl.

3) which key sizes to accept, regardless of cipher.

4) whether to use ephemeral keys.  (You might wish to disable 
ephemeral keys so you can use a SSL-aware network sniffer to 
monitor database traffic for debugging purposes.)

Identification parameters:

1) where the private key(s) and cert(s) are located.  Plural, 
since we want to be able to support both RSA and DSA keys.

2) where the additional support files, e.g., the DSA or DH 
parameters file used for ephemeral keys, are located.

3) where root certificate(s) are stored, used for authentication.

Logging parameters:

1) whether to log SSL connections

2) how much to log

3) how to log (log files, syslog, etc.)

Authentication parameters:

1) whether the client should authenticate the server's cert, and 
how to authenticate it.  (Simple enumeration of valid certs, or 
something based on PKIX?)

2) whether the server should require client certs, and how to 
authenticate them.  (Again, a simple enumeration of valid certs, 
or something based on PKIX?)

3) support for a mapping from authenticated client cert to 
PostgreSQL user id?


The server policy is easy to handle - it would probably go into a 
new text configuration file pg_ssl.conf.

The client policy is much harder to handle, since the details need 
to be hidden in the libpg library.  I know how to handle this on 
Unix systems, but what about clients on other platforms?  E.g., on 
a Windows box I would expect this information to be maintained in 
the registry, not a config file....


A sample (server) configuration file might look something like:

#
#    PostgreSQL SSL configuration file
#

# SSL protocol to use (SSLv2, SSLv3, SSLv23, TLSv1)
# Protocol SSLv23
Protocol TLSv1

# SSL ciphers to use
# Ciphers *

# keysize to use (min, max)
# Keysize *,*
Keysize 1024, *

# should ephemeral keys be used?
# Ephemeral yes

# location of keys
BaseDirectory  /opt/postgresql/data
RSAPrivateKey  rsa.private
RSACertificate rsa.crt

DSAKeyPairFile dsa.private
DSACertificate dsa.crt

# location of additional files
DHParameters   dh.pem
CADirectory    ca
CertDirectory  certs

# require client certificates?
# RequireClientCert no


Comments?

Bear


Sat, 28 Dec 2002 14:53:25 -0700
Bear Giles <bgiles@coyotesong.com>
next set of SSL - ideas?
Bear Giles writes:

> The server policy is easy to handle - it would probably go into a
> new text configuration file pg_ssl.conf.

postgresql.conf should serve you fine.

> The client policy is much harder to handle, since the details need
> to be hidden in the libpg library.  I know how to handle this on
> Unix systems, but what about clients on other platforms?  E.g., on
> a Windows box I would expect this information to be maintained in
> the registry, not a config file....

For libpq, put the required files in the home directory or some directory
under the home directory.  That should be acceptable on Windows, too, for
now.  ODBC and JDBC have their own way of storing client side
configuration, which you can discuss with their teams.

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 5 Jan 2003 03:11:37 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: next set of SSL - ideas?