Greetings, On Sat, Dec 9, 2023 at 18:02 David G. Johnston <david.g.johns...@gmail.com> wrote:
> On Saturday, December 9, 2023, Stephen Frost <sfr...@snowman.net> wrote: > >> >> >> The idea is that you can use both TLS and GSSAPI-with-encryption at the >> same time within a given cluster for connections but you wouldn’t use them >> on the same connection. Certainly would welcome suggestions as to the best >> way to phrase that. >> > > It isn’t really connection driven though - or even specific to these two > options. The pg_hba.conf file can contain any number of different > authentication methods that are usable simultaneously (from the perspective > of the cluster). But a given login request is only going to match a single > one of those lines; so it isn’t like the client somehow decides during each > login using the same machine and user name which way they are going to > verify who they say they are. > Not sure how it isn’t connection driven- as mentioned, the options are available and can be used at the same time but only on independent connections. > Didn’t mean to suggest it was really up to the client. Also- you can use TLS with GSSAPI, just not with GSSAPI-with-encryption. We don’t call out being able to use password and peer simultaneously, the > description and specification of the pg_hba.conf file itself imparts that > information. I’m unclear why these two would warrant a special calling out. > Cross verification between client and server with encryption…. Perhaps SCRAM with channel binding and TLS could also be listed. Password doesn’t provide this security, nor does LDAP, nor PAM. Peer doesn’t provide encryption (tho fair that it isn’t really necessary, but that doesn’t make it meet the criteria or intention of this). Thanks, Stephen >
