Re: Letting the client choose the protocol to use during a SASL exchange
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2017-04-06T20:16:10Z
Lists: pgsql-hackers
On 6 April 2017 at 16:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Perhaps we could turn this around: have the client send (in the connection > request packet) a list of auth protocols it thinks it is able to handle. > (I'm envisioning this as being more or less fixed for any one version of > any one client, since it would basically mean "I have code to do X, Y, or > Z".) Then the server can pick one that is allowed by pg_hba.conf, +1 Much better plan. > or it > can just ignore the list and send what it wants anyway, probably leading > to client disconnect. It would need to follow one of the requested protocols, but mark the request as doomed. Otherwise we'd be revealing information. That's what SCRAM does now. Since the list is currently length one, we can add more later when we get a list potentially > 1. > We could avoid this being a protocol break by having the server's default > assumption being that the client can handle all pre-SCRAM auth protocols. +1 -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Improve the SASL authentication protocol.
- 4f3b87ab780b 10.0 landed
-
Refactor libpq authentication request processing.
- 61bf96cab063 10.0 landed
-
Minor cleanup of backend SCRAM code.
- 00707fa58275 10.0 landed