Re: Postgres 11 release notes - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Postgres 11 release notes
Date
Msg-id d01b31f5-0b3e-b69a-1504-a79649d81f46@iki.fi
Whole thread Raw
In response to Re: Postgres 11 release notes  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Postgres 11 release notes  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 16/05/18 07:22, Michael Paquier wrote:
> On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
>> What TLS does is to mix the offered ciphers into the negotiation hash so
>> a man-in-the-middle can't pretend it doesn't support something.  Could
>> we do something like that here?
> 
> I have to admit that I don't quite follow here, the shape of channel
> binding data is decided by RFC 5929, so we need to stick with it.
> 
>> I have to question the value of man-in-the-middle protection that is so
>> easily bypassed.
> 
> Well, the backend does its job, and answers based on what the client
> wants to do.  But what you are questioning here is the handling of
> authentication downgrade attempts from a server by libpq, which is a
> different problem, larger than just channel binding as it relates as
> well to MD5/SCRAM interactions.  For example, it is perfectly possible
> to implement downgrade protections for any drivers which speak the
> protocol, like JDBC, even with a v11 backend.

I have to agree with Bruce, that it's pretty useless to implement 
channel binding, if there is no way to require it in libpq. IMHO that 
must be fixed.

It's true that even if libpq doesn't implement it, other drivers like 
JDBC could. Good for them, but that still sucks for libpq.

- Heikki


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
Next
From: Etsuro Fujita
Date:
Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.