I wrote: > So this directly explains the original report: if the only applicable > pg_hba.conf entry is "hostssl", right here is where libpq will see > that error, and it will go around and fail again because the next > try uses neither GSS nor SSL. > However, in the tests Mikael ran after backing that pg_hba.conf entry > off to just "host", pg_hba wouldn't have caused an authentication-stage > failure, so it's not so clear why we'd have looped back at this step. > We'd need to explain the later cases to have a full theory. It's > plenty plausible that something else caused an auth-stage failure, > but if so, why would the second GSS-free try work? So, after actually trying to reproduce this error, the answer to that question is blindingly obvious: 2020-12-26 15:34:01.425 EST [1853] FATAL: GSSAPI encryption can only be used with gss, trust, or reject authentication methods You'll recall that Mikael was using PAM auth; I hit this with just regular password auth. So, given that the server and client are in a Kerberos-enabled environment, they'll negotiate a GSS-encrypted connection (that the user did not ask for), then the server refuses to use it because of the above restriction, then libpq drops down to a new connection ... which, because of this allow_ssl_try bug, is not SSL-encrypted but just plain, even if the user had set sslmode=require. I'd say this is not just a nasty bug, but verges on requiring a CVE. I'm also of the opinion that this restriction on authentication type is useless damfool nannyism, and we should just drop it. Sure, if you've managed to GSS-ify the connection then the client is known to the Kerberos system, but that proves little about whether the client is entitled to log into the database under the username he's asking for. Why should we restrict how that auth is done? Even if there's some reason to do so, it's hard to believe that the reason justifies forcing a whole new round of encrypted-connection setup to switch to SSL encryption, when we have a perfectly good encrypted connection already. regards, tom lane PS: AFAICS, it's also undocumented useless damfool nannyism.
