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
