Re: Protocol problem with GSSAPI encryption?

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Sun, Dec 1, 2019 at 01:13:31AM +0000, Andrew Gierth wrote:
> > This came up recently on IRC, not sure if the report there was passed on
> > at all.
> >
> > ProcessStartupPacket assumes that there will be only one negotiation
> > request for an encrypted connection, but libpq is capable of issuing
> > two: it will ask for GSS encryption first, if it looks like it will be
> > able to do GSSAPI, and if the server refuses that it will ask (on the
> > same connection) for SSL.
>
> Are you saying that there is an additional round-trip for starting all
> SSL connections because we now support GSSAPI, or this only happens if
> libpq asks for GSSAPI?

The way that this is intended to work is if, and only if, there's is a
valid GSS credentical cache (on the client side) will GSSAPI encryption
be attempted and then if that fails because the server doesn't support
GSSAPI encryption of it's not possible to acquire credentials for
whatever reason then we'll fall back to other methods.

I have heard, however, that the Applie GSS libraries are both outright
broken (they lie about a valid credential cache existing- claiming one
does even when that's clearly not the case, based on klist..), and
deprecated (so they aren't likely going to fix them either..). We're
currently looking to see if there's a way to basically detect the Apple
GSS libraries and refuse to build if we discover that's what we're
building against. I'm not sure what other choice we really have...

If you gdb psql, without a Kerberos credential cache, on a system that
has a working GSS library, you'll note that pg_GSS_have_cred_cache()
returns false, meaning we skip over the GSS startup code in
PQconnectPoll() (and drop down to trying to do SSL next).

Thanks,

Stephen