On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier
> On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost <sfr...@snowman.net> wrote:
>> What I find somewhat objectionable is the notion that if we don't have 5
>> different TLS/SSL implementations supported in PG and that we've tested
>> that channel binding works correctly among all combinations of all of
>> them, then we can't accept a patch implementing it.
> It seems to me that any testing in this area won't fly high as long as
> there is no way to enforce the list of TLS implementations that a
> server allows. There have been discussions about being able to control
> that after the OpenSSL vulnerabilities that were protocol-specific and
> there were even patches adding GUCs for this purpose. At the end,
> everything has been rejected as Postgres enforces the use of the
> newest one when doing the SSL handshake.
TLS implementations, or TLS versions? What does the TLS version have
to do with this issue?
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: