Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote: > > On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: > >> Well, it'd be useless for users, there is no reason to switch off channel > >> binding if both the client and server support it. It might not add any > >> security you care about, but it won't do any harm either. The > >> non-channel-binding codepath is still exercised with non-SSL connections. > > > > Is that true? What if it makes a connection fail that you wanted to > > succeed? Suppose we discover a bug that makes connections using > > channel binding fail on Thursdays. > > Well, as things stand today on HEAD, if channel binding has a bug, this > makes the SCRAM authentication not able to work over SSL, hence you need > to either drop SSL, SCRAM or patch libpq so as the client tells the > server that it does not want to use channel binding. None of those are > appealing. Before 7729113, the client still had the choice to enforce > channel binding to not be used over SSL, which I think is a win to > bypass any potential future bugs. On top of that, we can test > automatically for *any* future SSL implementations that (SSL + SCRAM + > no channel binding) actually works properly, which is, it seems at least > to me, a good thing to get more confidence when a new SSL implementation > is added.
Uh, really? We can come up with all kinds of potential bugs that might exist in the world but I don't think we should be writing in options for everything that might fail due to some bug existing that we don't know about. Also, we aren't going to release support for a new SSL library in a minor release, so if we end up needing this option due to some SSL library that we really want to support not having channel binding support then we can add the option then (or realize that maybe we shouldn't be bothering with adding support for an SSL implementation that doesn't support channel binding.... it's not exactly a new thing these days and there's very good reasons for having it). Now- if we thought that maybe there was some connection pooling solution that could be made to work with SSL+SCRAM if channel binding is turned off, then that's a use-case that maybe we should try and support, but this notion that we need to be able to turn it off because there might be a bug is hogwash, imv. Now, I haven't seen a pooling solution actually figure out a way to do SSL+SCRAM even without channel binding, and there might not even be a way, so I'm currently a -1 on adding an option to disable it, but if someone turned up tomorrow with an credible approach to doing that, then I'd +1 adding the option. Thanks! Stephen
signature.asc
Description: PGP signature
