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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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:
/messages/by-id/20140110061253.46E0E153E0AE@machamp.omnigroup.com
/messages/by-id/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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers