Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Дата
Msg-id CA+TgmoYH=T1Hp9p0n3aT6b=A5kjtTb1GmwXDiGTtoLz3coWe9Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Channel binding support for SCRAM-SHA-256  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jun 6, 2017 at 2:32 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>>> 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.

I don't think it's true that we force the latest TLS version to be
used.  The comment says:

        /*
         * We use SSLv23_method() because it can negotiate use of the highest
         * mutually supported protocol version, while alternatives like
         * TLSv1_2_method() permit only one specific version.  Note
that we don't
         * actually allow SSL v2 or v3, only TLS protocols (see below).
         */

IIUC, this is specifically so that we don't force the use of TLS 1.2
or TLS 1.1 or TLS 1.0.

It could well be that there's something I don't understand here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Extra Vietnamese unaccent rules
Следующее
От: Kevin Hale Boyes
Дата:
Сообщение: Re: [HACKERS] sketchy partcollation handling