|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Cc:||Postgres hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Handling better supported channel binding types for SSL implementations|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 23 Jan 2018, at 03:24, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Mon, Jan 22, 2018 at 04:52:11PM +0100, Daniel Gustafsson wrote:
>> Not really, but IIUC a bug in this code could lead to channel binding
>> not being used for a connection even if the user wanted it (and may
>> miss that ixt didn’t happen due to not looking at logs etc)?
> Possible, if an implementation decides to send a NIL list as return
> result of this API when it should not.
>> Considering the limited set of values (currently) it should be quite
>> simple to check for offending entries, if there is indeed a risk of
>> “silently” not using channel binding.
> I think I understand the point you are coming at, but a problem is that
> the channel binding type the client wants to use is known by the server
> in SCRAM authentication only after reading the client-first message,
> which happens of course after the client decided to choose if channel
> binding is used or not. Now the server needs to emit first a list of
> supported SASL mechanisms which are consistent with what the SSL
> implementation can do when the mechanism is negotiated. Another, third
> approach that I can think of is to have this additional API in betls
> emit a list of mechanisms, but I am not sure that this is worth the
> complication as at the end what you want to know is if at least one
> channel binding type is supported or not.
Thanks for the explanation, I agree that the proposed approach makes the most
> We could as well live with the existing set of betls APIs, just that the
> implementation of secure transport for MacOS will need a hack in auth.c
> to stop the -PLUS mechanisms to be sent. Putting this load into each
> be-secure-*.c file is cleaner in my opinion.
I completely agree, let’s avoid such hacks.
|Next Message||Tom Lane||2018-01-23 14:46:32||Re: pg_upgrade tests failing on current master|
|Previous Message||Marco Nenciarini||2018-01-23 14:38:45||Re: [PATCH] Logical decoding of TRUNCATE|