Обсуждение: Postgres and TLSv1.2
G'Day guys, after exploiting all the other sources, I've reached the point where I need to use this final option to get some help. We are trying to setup Postgres with TLSv1.2 (undergoing PA:DSS audit), but getting a bit stuck there with Postgres reporting “could not accept SSL connection: no shared cipher”. This is obviously an internal OpenSSL message, but worrying part is that we've had this setup running with the other encryptions and the same certificates without any problems. We've been trying to follow documentation from here: http://www.postgresql.org/docs/9.3/static/ssl-tcp.html. making changes in /etc/postgresql/9.3/main/postgresql.conf: <before> ssl = true #ssl_ciphers = 'DEFAULT:!LOW:!EXP:!MD5:@STRENGTH' #ssl_renegotiation_limit = 512MB ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem' ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key' #ssl_ca_file = '' #ssl_crl_file = '' #password_encryption = on #db_user_namespace = off </before> <after> ssl = true ssl_ciphers = 'TLSv1.2:!aNULL' #ssl_renegotiation_limit = 512MB ssl_cert_file = '/var/lib/postgresql/9.3/main/server.crt' ssl_key_file = '/var/lib/postgresql/9.3/main/server.key' ssl_ca_file = '/var/lib/postgresql/9.3/main/root.crt' #ssl_crl_file = '' #password_encryption = on #db_user_namespace = off </after> logon string: postgresql://bp-node@172.27.72.45/bp-node?sslmode=require latest OpenSSL available. $ openssl ciphers -v 'TLSv1.2:!aNULL' returns all cyphers Once again - Certificates should be fine as this seem to work for any other encryptions. Can I have your advice please? Kind Regards, Jan Jan Bilek CTO, EFTlab Pty Ltd email:jan.bilek@eftlab.co.uk mob: +61 (0) 498 103 179 Note: When we've been doing the SSL/TLS implementation for our product, we've encountered same problem when SSL context was initialised after the SSL socket, so socket creation was done "on empty CTX". But that was for all encryptions.
Jan Bilek <jan.bilek@eftlab.co.uk> writes: > We are trying to setup Postgres with TLSv1.2 (undergoing PA:DSS audit), > but getting a bit stuck there with Postgres reporting “could not accept > SSL connection: no shared cipher”. This is obviously an internal OpenSSL > message, but worrying part is that we've had this setup running with the > other encryptions and the same certificates without any problems. > We've been trying to follow documentation from here: > http://www.postgresql.org/docs/9.3/static/ssl-tcp.html. 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. I don't recall why we didn't back-patch that change, probably excessive concern for backwards compatibility ... but anyway, AFAICS from the git logs, it's not in 9.3.x. I think you could get TLS 1.2 from a 9.3 server and 9.4 libpq, if that helps. regards, tom lane
I wrote: > 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. > I don't recall why we didn't back-patch that change, probably excessive > concern for backwards compatibility ... but anyway, AFAICS from the git > logs, it's not in 9.3.x. I think you could get TLS 1.2 from a 9.3 server > and 9.4 libpq, if that helps. Looking back at the discussions, it seems the reason we only changed HEAD is that the change to let libpq negotiate TLS > v1 got conflated with modifying the server to reject SSL v3. See threads here: http://www.postgresql.org/message-id/flat/20140110061253.46E0E153E0AE@machamp.omnigroup.com#20140110061253.46E0E153E0AE@machamp.omnigroup.com http://www.postgresql.org/message-id/flat/E1W6rB1-0000go-Ij@gemulon.postgresql.org and particularly commits 820f08cabdcbb899 and 326e1d73c476a0b5. I think this was probably a mistake. I suggest that in the back branches we should leave the server alone (rejecting SSL v3 might annoy somebody using old non-libpq clients) but adjust libpq to use SSLv23_method() plus SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3. IOW, back-patch 820f08cabdcbb899, though perhaps also the comment adjustments in 326e1d73c476a0b5. This would have the effect of allowing libpq to use TLS-anything, not only TLSv1 which is what it's been requiring since 7.3.2. Thoughts? regards, tom lane
On 22/05/15 02:06, Tom Lane wrote: > Jan Bilek <jan.bilek@eftlab.co.uk> writes: >> We are trying to setup Postgres with TLSv1.2 (undergoing PA:DSS audit), >> but getting a bit stuck there with Postgres reporting “could not accept >> SSL connection: no shared cipher�. This is obviously an internal OpenSSL >> message, but worrying part is that we've had this setup running with the >> other encryptions and the same certificates without any problems. >> We've been trying to follow documentation from here: >> http://www.postgresql.org/docs/9.3/static/ssl-tcp.html. > 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. > > I don't recall why we didn't back-patch that change, probably excessive > concern for backwards compatibility ... but anyway, AFAICS from the git > logs, it's not in 9.3.x. I think you could get TLS 1.2 from a 9.3 server > and 9.4 libpq, if that helps. > > regards, tom lane That explains it whole. Thank you for your fast and clear answer. Best, Jan
I wrote: > I think this was probably a mistake. I suggest that in the back branches > we should leave the server alone (rejecting SSL v3 might annoy somebody > using old non-libpq clients) but adjust libpq to use SSLv23_method() plus > SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3. IOW, back-patch 820f08cabdcbb899, > though perhaps also the comment adjustments in 326e1d73c476a0b5. > This would have the effect of allowing libpq to use TLS-anything, not only > TLSv1 which is what it's been requiring since 7.3.2. Done at http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c6b7b9a9cef1253ad12122959d0e78f62d8aee1f This is too late for tomorrow's releases, but it will be in the next minor releases --- or if you're in a hurry, you could apply that patch locally. regards, tom lane
On 22/05/15 10:45, Tom Lane wrote: > I wrote: >> I think this was probably a mistake. I suggest that in the back branches >> we should leave the server alone (rejecting SSL v3 might annoy somebody >> using old non-libpq clients) but adjust libpq to use SSLv23_method() plus >> SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3. IOW, back-patch 820f08cabdcbb899, >> though perhaps also the comment adjustments in 326e1d73c476a0b5. >> This would have the effect of allowing libpq to use TLS-anything, not only >> TLSv1 which is what it's been requiring since 7.3.2. > Done at > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c6b7b9a9cef1253ad12122959d0e78f62d8aee1f > > This is too late for tomorrow's releases, but it will be in the next minor > releases --- or if you're in a hurry, you could apply that patch locally. > > regards, tom lane This is excellent! Thank you! Kind Regards, Jan