From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gustavsson Mikael <mikael.gustavsson@smhi.se>
cc: Stephen Frost <sfrost@snowman.net>, 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>
Subject: Re: SV: SV: SV: SV: Problem with ssl and psql in Postgresql 13
In-reply-to: <723586.1608740901@sss.pgh.pa.us>
References: <e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se>
 <20201217.172938.170511532557914014.horikyota.ntt@gmail.com>
 <06191eae74d045e192a786a84a73ba53@smhi.se> <65644.1608214801@sss.pgh.pa.us>
 <a748b98ff0a94fe0a1ca54872ec5a25e@smhi.se>
 <CABUevEz0tuQzXYmgDGDsbhs+8V-WOp2cSpM1S70S5L+gSDRGUg@mail.gmail.com>
 <a9e6ef756df24fba948b5c09b1f30229@smhi.se>,<CABUevEz_eHh=R6C_C7GChF8w_aG4pMPDAvjJFa92cspAb3SSkg@mail.gmail.com>
 <698125e1105644adaa27578bb37b18f6@smhi.se>,<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>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 23 Dec 2020 11:28:21 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <737385.1608757126.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Dec 2020 15:58:46 -0500
Message-ID: <737386.1608757126@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Gustavsson Mikael <mikael.gustavsson@smhi.se> writes:
>> So if i set gssencmode=3Ddisable on my pgsql-13 to postgres 13 server c=
onnection i get an SSL connection.

> It looks like, if there is a credentials cache and gssencmode isn't
> explicitly disabled, we try GSS first.  If the server refuses that:
> ...
> that is, it decides the connection it has is good enough.  This
> is not OK if SSL should have been used.

No, I misread the code; what will happen next is that an SSL connection
will be tried.  At least, it looks like that should happen, and it does
happen for me.

However: it is true (and undocumented, so we have at least a docs bug
to fix) that v12-and-later libpq will try for GSS encryption first,
and if it succeeds then it will not consider using SSL, regardless of
sslmode.  So about 95% of your report could be explained by assuming
that you have a working Kerberos environment and the newer libpq is
preferring GSS encryption over SSL.  There is just one thing this
theory is failing to explain: instead of "SSL connection", psql
should have printed "GSSAPI-encrypted connection" in your test
shown in <d3ab9042bce34aae85d323d69e3ee430@smhi.se>.  It didn't,
so this can't be the true explanation.  I think what must be
happening is that libpq is trying for GSS (hence you have at least
a credentials cache somewhere), failing to establish it, and then
for some reason advancing to the startup-packet step without
trying for SSL.  But I can't see how to get the state machine to
do that.

Have you got any environment variables, service files, etc
that would affect libpq's behavior?

			regards, tom lane