next set of SSL - ideas?
От | Bear Giles |
---|---|
Тема | next set of SSL - ideas? |
Дата | |
Msg-id | 3E0E1D55.9020108@coyotesong.com обсуждение исходный текст |
Ответы |
Re: next set of SSL - ideas?
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: