Greetings, * Tom Lane (tgl@xxxxxxxxxxxxx) wrote: > Stephen Frost <sfrost@xxxxxxxxxxx> writes: > > * Tom Lane (tgl@xxxxxxxxxxxxx) 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@xxxxxxx>. 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". Sure, that seems alright to me. > 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? There are certainly some very odd GSSAPI implementations out there (including hacked up things particularly on Macs that we've seen..), though I've not run into one where I've seen that call fail. If it did fail though, surely the error messages would make that clear, and we're not seeing that here..? If we do succeed with a GSS connection (which seems extremely unlikely to just happen without the individual setting the system up knowing that they've created an appropriate Kerberos keytab with a postgres service princ...), then, as you say up-thread, psql should have printed out that we made a GSSAPI encrypted connection. I'm not sure how, but it sure seems like somehow, in this case, we're going through the GSSAPI encryption code because we find GSSAPI credentials (entirely possible, even if you're not using them for talking to PG), the server responds with a "I haven't got support for that" in some fashion, and we're skipping SSL at that point. How that's happening isn't clear to me though, but the idea that it's because gss_wrap_size_limit() is failing seems very unlikely. Thanks, Stephen
Attachment:
signature.asc
Description: PGP signature
