On Fri, Jun 2, 2017 at 10:25 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> 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?
I really mean *version* here. Unlike OpenSSL, the Windows TLS
implementation does not offer an API to choose the latest TLS version
available:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa380513(v=vs.85).aspx
It is up to the server and the client to negotiate that, so it seems
to me that we want some control in this area, which would be important
for testing as well because the TLS finish message differs a bit
across versions, in length mainly. On top of that per the aggressive
updates that Windows does from time to time they may as well forcibly
expose users to a broken TLS implementation...
MacOS has something similar to OpenSSL, with
SSLGetProtocolVersionMax(), which is nice.
--
Michael