Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to configure TLS 1.1 protocol for SSL connection in PostgreSQL.

I was not able to see protocol setting in the PostgreSQL configuration

It is required to disable SSL protocols and TLSv1 and enable only TLSv1.1 (or TLSv1.2)

Added

PCI DSS v3.1 requires that fallback to SSL and TLSv1 will be disabled.

Is it is possible to configure PostgreSQL to negotiate using TLSv1.1 only?

If you know that it is impossible please share this information

Added 2

Unfortunately, the configuration of ssl_ciphers is not enough since you can use same ciphers for different protocols. It is required to configure SSL_METHOD as described here: https://www.openssl.org/docs/manmaster/ssl/ssl.html.

My conclusion that the configuration of SSL_METHOD (or SSL_PROTOCOL) is missed from the PostgreSQL configuration and it can not be complaint to PCI DSS 3.1.

Please correct me if I am wrong.

share|improve this question
4  
Tom says: "libpq versions before 9.4 will only accept TLSv1 exactly. In 9.4 it should negotiate the highest TLS version supported by both server and client." So you might be out of luck on 9.1. – Josh Kupershmidt Sep 18 '15 at 14:04
    
Is upgrading to 9.3 (preferably 9.4) an option? – dezso Oct 1 '15 at 8:19
    
@dezso I have changed my question to version 9.4. Any case, I did not find in the configuration option to configure TLS 1.1 protocol for SSL connection. – Michael Oct 1 '15 at 10:07

@BrianEfting was correct, you can specify the appropriate cipher suites to only allow TLSv1.2 which should fit your PCI-DSS 3.1 specification needs.

Using a cipher list like this in the ssl_ciphers option in your postgresql.conf:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

along with setting ssl_prefer_server_ciphers=true, should be sufficient to allow only TLSv1.2 connections.

You can verify this using SSLyze which knows about the PostgreSQL protocol.

To test, I used the following command:

./sslyze.py --sslv2 --sslv3 --tlsv1 --tlsv1_1 --tlsv1_2 localhost:5432 --starttls=postgres --hide_rejected_ciphers

Which gave the output below under PostgreSQL 9.4 on Debian Wheezy showing that all cipher suites except for the TLSv1.2 ciphers specified were rejected, which should satisfy the requirements of PCI-DSS 3.1 by using TLSv1.1 or greater.

postgres@pgsqlsec4:~/sslyze$ ./sslyze.py --sslv2 --sslv3 --tlsv1 --tlsv1_1 --tlsv1_2 localhost:5432 --starttls=postgres --hide_rejected_ciphers



 AVAILABLE PLUGINS
 -----------------

  PluginCompression
  PluginHeartbleed
  PluginChromeSha1Deprecation
  PluginSessionRenegotiation
  PluginOpenSSLCipherSuites
  PluginSessionResumption
  PluginHSTS
  PluginCertInfo



 CHECKING HOST(S) AVAILABILITY
 -----------------------------

   localhost:5432                      => ::1:5432



 SCAN RESULTS FOR LOCALHOST:5432 - ::1:5432
 ------------------------------------------

  * SSLV2 Cipher Suites:
      Server rejected all cipher suites.

  * TLSV1_2 Cipher Suites:
      Preferred:                       
                 ECDHE-RSA-AES128-GCM-SHA256   ECDH-256 bits  128 bits                                         
      Accepted:                        
                 ECDHE-RSA-AES256-SHA384       ECDH-256 bits  256 bits                                         
                 ECDHE-RSA-AES256-GCM-SHA384   ECDH-256 bits  256 bits                                         
                 DHE-RSA-AES256-SHA256         DH-1024 bits   256 bits                                         
                 DHE-RSA-AES256-GCM-SHA384     DH-1024 bits   256 bits                                         
                 ECDHE-RSA-AES128-SHA256       ECDH-256 bits  128 bits                                         
                 ECDHE-RSA-AES128-GCM-SHA256   ECDH-256 bits  128 bits                                         
                 DHE-RSA-AES128-SHA256         DH-1024 bits   128 bits                                         
                 DHE-RSA-AES128-GCM-SHA256     DH-1024 bits   128 bits                                         

  * TLSV1_1 Cipher Suites:
      Server rejected all cipher suites.

  * TLSV1 Cipher Suites:
      Server rejected all cipher suites.

  * SSLV3 Cipher Suites:
      Server rejected all cipher suites.



 SCAN COMPLETED IN 0.73 S
 ------------------------
postgres@pgsqlsec4:~/sslyze$
share|improve this answer
    
It is the workaround. Once again: it is required to configure protocol and it is missed from PostgreSQL configuration. I can not accept the answer. Any case, I do not have a problem to give a bounty for the hard work. – Michael Oct 6 '15 at 11:13

From the following link:

18.3. Connections and Authentication (PostgreSQL 9.4 Manual)

It would appear that you can use the ssl_ciphers option to specify your list of accepted ciphers. And it mentions that it follows whatever your version of OpenSSL supports.

And in this link:

OpenSSL Ciphers (OpenSSL.org)

Mentions that there is no specific ciphersuite for TLSv1.1 but you can specify TLSv1.2.

share|improve this answer
    
Unfortunately, the configuration of ssl_ciphers is not enough since you can use same ciphers for different protocols. It is required to configure SSL_METHOD as described here: openssl.org/docs/manmaster/ssl/ssl.html. My conclusion that the configuration of SSL_METHOD (or SSL_PROTOCOL) is missed from the PostgreSQL configuration and it can not be complaint to PCI DSS 3.1. Please correct me if I am wrong. – Michael Oct 4 '15 at 8:23
    
I can not accept the answer. Any case, I do not have a problem to give a bounty for the hard work. – Michael Oct 7 '15 at 6:52
    
Well thank you Michael. I think @Kassandry worked harder than I did, though, and deserves some serious props here. Even going so far as to test and see that the insecure methods are indeed rejected. – Brian Efting Oct 7 '15 at 18:12
    
Yes, but you was the first with this approach. Unfortunately, I can not spit the bounty – Michael Oct 8 '15 at 10:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.