Re: Problem with ssl and psql in Postgresql 13
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Gustavsson Mikael <mikael.gustavsson@smhi.se>,
Magnus Hagander <magnus@hagander.net>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
"pgsql-general@postgresql.org" <pgsql-general@postgresql.org>,
Svensson Peter <peter.svensson@smhi.se>
Date: 2020-12-26T21:00:10Z
Lists: pgsql-general
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.
Commits
-
Fix up usage of krb_server_keyfile GUC parameter.
- 861e967176e9 13.2 landed
- 860fe27ee1e2 14.0 landed
- 3ca19490b4f8 12.6 landed
-
Improve log messages related to pg_hba.conf not matching a connection.
- d05e14d786ac 13.2 landed
- 7ed616f818f0 12.6 landed
- 3995c424984e 14.0 landed
-
Fix assorted issues in backend's GSSAPI encryption support.
- c1c88bf03e1e 13.2 landed
- 622ae4621ece 14.0 landed
- 4cfdd8a47a9e 12.6 landed
-
Fix bugs in libpq's GSSAPI encryption support.
- ff6ce9a3a691 14.0 landed
- b3a5bf719cf7 12.6 landed
- 06b844c2b8d3 13.2 landed