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. -- Michael
signature.asc
Description: PGP signature
