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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Дата
Msg-id 20171222025908.GA11776@paquier.xyz
обсуждение исходный текст
Ответ на 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  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Dec 20, 2017 at 09:35:55AM +0900, Michael Paquier wrote:
> However, it is possible to simply optimize the frontend code as in
> pg_SASL_init() we already know the channel binding type selected when
> calling pgtls_get_finished() and pgtls_get_peer_certificate_hash(). So
> while I agree with your point, my opinion is to keep the code as
> simple as possible, and then just optimize the frontend code. What do
> you think?

I have looked at how things could be done in symmetry for both the frontend
and backend code, and I have produced the attached patch 0002, which
can be applied on top of 0001 implementing tls-server-end-point. This
simplifies the interfaces to initialize the SCRAM status data by saving
into scram_state and fe_scram_state respectively Port* and PGconn* which
holds most of the data needed for the exchange. With this patch, cbind_data
is generated only if a specific channel binding type is used with the
appropriate data. So if no channel binding is used there is no additional
SSL call done to get the TLS finished data or the server certificate hash.

0001 has no real changes compared to the last versions.

Peter, thoughts?
--
Michael

Вложения

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

Предыдущее
От: Gene Selkov
Дата:
Сообщение: Re: genomic locus
Следующее
От: Thomas Munro
Дата:
Сообщение: Condition variable live lock