Thread: Channel binding
We removed channel binding from PG 11 in August of 2018 because we were concerned about downgrade attacks. Are there any plans to enable it for PG 12? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote: > We removed channel binding from PG 11 in August of 2018 because we were > concerned about downgrade attacks. Are there any plans to enable it for > PG 12? The original implementation of channel binding for SCRAM has included support for two channel binding types: tls-unique and tls-server-end-point. The original implementation also had a connection parameter called scram_channel_binding to control the channel binding type to use or to disable it. What has been removed via 7729113 are tls-unique and the libpq parameter, and we still have basic channel binding support. The reasons behind that is that tls-unique future is uncertain as of TLS 1.3, and that tls-server-end-point will still be supported. This also simplified the protocol as it is not necessary to let the client decide which channel binding to use. Downgrade attacks at protocol level are something different though, as it is possible to trick libpq to lower down the initial level of authentication wanted (say from SCRAM to MD5, or even worse from MD5 to trust). What we need here is additional frontend facility to allow a client to authorize only a subset of authentication protocols. With what's is v11 and HEAD, any driver speaking the Postgres protocol can implement that. -- Michael
Attachment
On Sat, Feb 16, 2019 at 10:12:19AM +0900, Michael Paquier wrote: > On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote: > > We removed channel binding from PG 11 in August of 2018 because we were > > concerned about downgrade attacks. Are there any plans to enable it for > > PG 12? > > The original implementation of channel binding for SCRAM has included > support for two channel binding types: tls-unique and > tls-server-end-point. The original implementation also had a > connection parameter called scram_channel_binding to control the > channel binding type to use or to disable it. > > What has been removed via 7729113 are tls-unique and the libpq > parameter, and we still have basic channel binding support. The > reasons behind that is that tls-unique future is uncertain as of TLS > 1.3, and that tls-server-end-point will still be supported. This also > simplified the protocol as it is not necessary to let the client > decide which channel binding to use. Well, my point was that this features was considered to be very important for PG 11, but for some reason there has been no advancement of this features for PG 12. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Fri, Feb 15, 2019 at 10:21:12PM -0500, Bruce Momjian wrote: > Well, my point was that this features was considered to be very > important for PG 11, but for some reason there has been no advancement > of this features for PG 12. Yeah, it is unfortunate that we have not seen patches about that or concrete proposals for a proper libpq patch. -- Michael