Re: Problem with ssl and psql in Postgresql 13

Greetings,

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

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