Re: Problems with GSS encryption and SSL in libpq in 12~

Greetings,

* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> On Mon, Apr 06, 2020 at 04:25:57PM +0900, Michael Paquier wrote:
> > It is possible to enforce this flag to false by using
> > gssencmode=disable, but that's not really user-friendly in my opinion
> > because nobody is going to remember that for connection strings with
> > SSL settings so a lot of application are taking a performance hit at
> > connection because of that in my opinion. I think that's also a bad
> > idea from the start to assume that we have to try GSS by default, as
> > any new code path opening a secured connection may fail into the trap
> > of attempting to use GSS if this flag is not reset. Shouldn't we try
> > to set this flag to false by default, and set it to true only if
> > necessary depending on gssencmode? A quick hack switching this flag
> > to false in makeEmptyPGconn() gives back the past performance to
> > src/test/ssl/, FWIW.
> >
> > Looking around, it seems to me that there is a second issue as of
> > PQconnectPoll(), where we don't reset the state machine correctly for
> > try_gss within reset_connection_state_machine, and instead HEAD does
> > it in connectDBStart().
>
> So, a lot of things come down to PQconnectPoll() here. Once the
> connection state reached is CONNECTION_MADE, we first try a GSS
> connection if try_gss is true, and a SSL connection attempt follows
> just after. This makes me wonder about the following things:
> - gssencmode is prefer by default, the same as sslmode. Shouldn't we
> issue an error if any of them is not disabled to avoid any conflicts
> in the client, making the choice of gssencmode=prefer by default a bad
> choice? It seems to me that there could be an argument to make
> gssencmode disabled by default, and issue an error if somebody
> attempts a connection without at least gssencode or sslmode set as
> disabled.

I don't see why it would make sense to throw an error and require that
one of them be disabled. I certainly don't agree that we should disable
GSS encryption by default, or that there's any reason to throw an error
if both GSS and SSL are set to 'prefer' (as our current default is).

> - The current code tries a GSS connection first, and then it follows
> with SSL, which is annoying because gssencmode=prefer by default means
> that any user would pay the cost of attempting a GSS connection for
> nothing (with or even without SSL). Shouldn't we do the opposite
> here, by trying SSL first, and then GSS?

A GSS connection is only attempted, as mentioned, if your GSS library
claims that there's a possibility that credentials could be acquired for
the connection.

> For now, I am attaching a WIP patch which seems like a good angle of
> attack for libpq, meaning that if sslmode and gssencmode are both set,
> then we would attempt a SSL connection before attempting GSS, so as
> any user of SSL does not pay a performance hit compared to past
> versions (I know that src/test/kerberos/ fails with that because
> sslmode=prefer is triggered first in PQconnectPoll(), but that's just
> to show the idea I had in mind).
>
> Any thoughts?

I don't agree with the assumption that, in the face of having GSS up and
running, which actually validates the client and the server, that we
should prefer SSL, where our default configuration for SSL does *not*
validate properly *either* the client or the server.

What it sounds like to me is that it'd be helpful for you to review why
your environment has a GSS credential cache (or, at least,
gss_acquire_cred() returns without any error) but GSS isn't properly
working. If you're using OSX, it's possible the issue here is actually
the broken and ridiculously ancient kerberos code that OSX ships with
(and which, in another thread, there's a discussion about detecting and
failing to build if it's detected as it's just outright broken). If
it's not that then it'd be great to understand more about the specific
environment and what things like 'klist' return.

Thanks,

Stephen