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_SSLv
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 820f08cabd
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 f
On 22/05/15 02:06, Tom Lane wrote:
Jan Bilek 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 worryin
Jan Bilek 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 thi
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: n
