Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1

Поиск
Список
Период
Сортировка
От Steven Fackler
Тема Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Дата
Msg-id CANb7cF5LU+TYHw6+p8tJnr+5adiSGHifGrGhh1StyhK+-m_=nA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Jun 6, 2018 at 2:21 PM Michael Paquier <michael@paquier.xyz> wrote:

Thanks for the pointers, Steven.  You should avoid top-posting on this
list, this is not the style used on the Postgres lists.

Ah sorry about that! Hopefully this looks better.
 
Does this mean that tls-server-end-point goes into unsupported mode?
The emails you mention (thanks!), talk about only tls-unique while the
RFCs mention all channel binding types.

That's the part that I'm unsure about - tls-server-end-point doesn't seem particularly objectionable. I asked for some clarification from the person that I was talking to earlier.
 
Please let me think about this one, I am not completely sure yet what
that would mean for libpq and the backend code.

On the backend, you can use SSL_session_reused to check if a session was resumed, and then use SSL_get_peer_finished if it wasn't and SSL_get_finished if it was. The libpq frontend library doesn't need to worry about it since it never attempts to reuse sessions.

Steven

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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: POC: GROUP BY optimization
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: POC: GROUP BY optimization