Re: Handling better supported channel binding types for SSL implementations

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
Date: 2018-01-23 14:42:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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.

cheers ./daniel

In response to

Browse pgsql-hackers by date

  From Date Subject
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