From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Gustavsson Mikael <mikael.gustavsson@smhi.se>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
Cc: Svensson Peter <peter.svensson@smhi.se>
Subject: Re: Problem with ssl and psql in Postgresql 13
Date: Sat, 26 Dec 2020 16:00:10 -0500
Message-ID: <1308863.1609016410@sss.pgh.pa.us> (raw)
In-Reply-To: <742641.1608762845@sss.pgh.pa.us>
References: <89909.1608222331@sss.pgh.pa.us>
<61e2a65bbc2f47d297a6f3cdac2cc6cc@smhi.se>
<d3ab9042bce34aae85d323d69e3ee430@smhi.se>
<169637.1608321770@sss.pgh.pa.us>
<c347c62b507743ceac0aaebd0ccff533@smhi.se>
<de4dc5a4f22d43a28300bccb70d99db6@smhi.se>
<723586.1608740901@sss.pgh.pa.us>
<737386.1608757126@sss.pgh.pa.us>
<20201223211448.GR27507@tamriel.snowman.net>
<738715.1608758847@sss.pgh.pa.us>
<20201223214534.GS27507@tamriel.snowman.net>
<740093.1608760567@sss.pgh.pa.us>
<742641.1608762845@sss.pgh.pa.us>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, mikael.gustavsson@smhi.se, magnus@hagander.net, horikyota.ntt@gmail.com, peter.svensson@smhi.se
Subject: Re: Problem with ssl and psql in Postgresql 13
In-Reply-To: <1308863.1609016410@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox