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

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

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?
--
Michael