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
Re: [HACKERS] Channel binding support for SCRAM-SHA-256 |
Список | 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 по дате отправления: