Re: Problem with ssl and psql in Postgresql 13

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> 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.

> 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.

Yeah; the problem is that the sslmode docs don't mention that GSS comes
first.  I was thinking of adding verbiage along the lines of "Note that
if GSS encryption is possible, that will be used in preference to SSL,
regardless of the value of sslmode".

In the meantime, I did spot a code path that would explain the symptoms:
pqsecure_open_gss() clears allow_ssl_try sooner than it oughta.  If
gss_wrap_size_limit() failed for some reason, we'd abandon the GSS
connection and try another one, and we would *not* try to SSL-ify
the new one.  While that's clearly a bug, I'm dubious that it explains
this report, because it hardly seems likely that gss_wrap_size_limit()
would fail when we've already successfully negotiated an encrypted
connection.  Can you think of a plausible reason for that to happen?

			regards, tom lane