Date: Wed, 23 Dec 2020 16:14:48 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
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>
Subject: Re: Problem with ssl and psql in Postgresql 13
Message-ID: <20201223211448.GR27507@tamriel.snowman.net>
References: 
 <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>
 <737386.1608757126@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="MdJ3p2aQbVp3YFXz"
Content-Disposition: inline
In-Reply-To: <737386.1608757126@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--MdJ3p2aQbVp3YFXz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I wrote:
> > Gustavsson Mikael <mikael.gustavsson@smhi.se> writes:
> >> So if i set gssencmode=3Ddisable on my pgsql-13 to postgres 13 server =
connection i get an SSL connection.
>=20
> > 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.
>=20
> 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.
>=20
> 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.

Not sure how much it helps, but yes, the general idea is that if you've
got a Kerberos credential cache, then we're going to try GSS encryption
first and, if that succeeds, we'll use it.

The docs do say this-

https://www.postgresql.org/docs/current/libpq-connect.html

under gssencmode / prefer (default)

if there are GSSAPI credentials present (i.e., in a credentials cache),
first try a GSSAPI-encrypted connection; if that fails or there are
no credentials, try a non-GSSAPI-encrypted connection. This is the
default when PostgreSQL has been compiled with GSSAPI support.

Though we also say under sslmode / prefer (default) -

first try an SSL connection; if that fails, try a non-SSL connection

Obviously they can't both be 'first', so it would probably make sense to
update the documentation, though exactly how I'm not sure.  Perhaps
under sslmode / prefer:

first try an SSL connection (note, however, that if there are GSSAPI
credentials present and gssencmode is also set to 'prefer', then a
GSSAPI-encrypted connection will be attempted first); if that fails, try
a non-SSL connection

?

Or perhaps a Note would be better to explain that we try GSSAPI
encryption first if GSSAPI credentials exist and both are set to
'prefer'.  The whole situation around 'prefer' is pretty grotty for all
cases, though I suppose that isn't really news these days.

Thanks,

Stephen

--MdJ3p2aQbVp3YFXz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJf47NIAAoJEO1sijiDR2RV6LMP/2gxo2QPsTRWIDIKL08AkfJe
iTPvz83OtSnwsXu3ZKIc6DIdmfSLBfSQSpt/n99YNrQgkSswCFRXRYqnU7ktKsNv
KJD3qZzuexaL6AGO1HAndeDAXrsDkEA1myxneJ3dKEX5HJxj32YNgLXVOAG57I8u
68PihZdTsqWQ6WECjHqjuW4UdR9JQX0bqZF101mpxFbVvpQmb1Dot3O0Dc5yGa+M
7U1p/HLgvWFnAre9ADxUuNO1Qv5h+fyEeK5wBZZl12KNDHa1PVPg95DwwFJ43OO8
t3gOs/vWhDt+N0WkcUIHRHMlzkdfqxBu7W2pDTxuVhWeIeUrBgky1cyxfleOjE4M
S9OpJv8Zmg0O2wUWgHtpfBu28BB2KehTRWWgShvphRePSVMGSXGNPfvj/F02uFF+
9ibJ/LeaU85EmRsU9wpxxyE+CxPmVG7pW/YoA8KQ5BaHaQ4qBsd+ejGk73OfYD+t
/BgReeaopthzC/gT+9UnViCdh4lc+FDP/6YIz34uwhcpGmbVGNvQMKZtCb9f+VCM
4tuVgKpCnYNyX2Eiuggjqdv1jYGPxD12RcJApyCEZfulvPgjiS+YtpSsJwD48RAz
vS302/SJqBofndseB5OoBRhwz9AgLm8foVK5QgxxcZ1mxz2SRcbZO2k7APi5xuX2
ndureJKCmXZSFpDC1Gy6
=2JBA
-----END PGP SIGNATURE-----

--MdJ3p2aQbVp3YFXz--