BUG #16897: gssenc request slow connection

Greetings,

* PG Bug reporting form (noreply@postgresql.org) wrote:

Email address: rich.crampton@gmail.com
PostgreSQL version: 12.6
Operating system: client Windows 10, postgresql server Ubuntu
Description:

When connecting over a local network from Windows 10 to PostgreSQL server
(Linux version 12.6 default install) the gssencmode=prefer in libpq
connection causes a big slowdown.

With "gssencmode=prefer" connection takes 4 seconds.
With "gssencmode=disable" connection as fast as normal.

As the prefer option is the default option this causes problems in dependent
libraries such as psycopg2 for Python. First raised the bug here
https://github.com/psycopg/psycopg2/issues/1242 but I think this must be a
libpq/Postgresql bug since psycopg2 is just passing along the request.

What's the version of the libpq library on the client side..? In
general, while there's an extra packet back and forth because Kerberos /
GSSAPI is set up on the client / Windows side, once the server says it
doesn't support GSSENC, libpq should try a non-GSSENC connection right
away..

Thanks,

Stephen

Hi,

The libpq version is 12.2. I've attached two images of the packets
transferred on a connection to my db with gssenc=prefer and
gssenc=disable. The client is 10.64.0.3 and the host is 10.64.0.7.
In the gssenc image packet 3155 is the gssenc request. I don't know what
the NBNS packets are doing but they seem to be the cause of the delay.

Cols: No, Time, Source, Destination, Protocol, Length, Info

Thx,
Richard

On Thu, 25 Feb 2021 at 17:43, Stephen Frost <sfrost@snowman.net> wrote:

Greetings,

* Richard Crampton (rich.crampton@gmail.com) wrote:

The libpq version is 12.2. I've attached two images of the packets
transferred on a connection to my db with gssenc=prefer and
gssenc=disable. The client is 10.64.0.3 and the host is 10.64.0.7.
In the gssenc image packet 3155 is the gssenc request. I don't know what
the NBNS packets are doing but they seem to be the cause of the delay.

First thing to do would certainly be to update to the latest libpq
release, there's been a number of improvements and bug fixes.

Thanks,

Stephen

I just upgraded to libpq=13.1 with no change in result. Is there anything
newer? I'm not sure whether it's relevant but my krb5 version is 1.17.1
and I can't upgrade this without breaking dependencies.

Thx,
Richard

On Thu, 25 Feb 2021 at 18:58, Stephen Frost <sfrost@snowman.net> wrote:

Stephen Frost <sfrost@snowman.net> writes:

What's the version of the libpq library on the client side..? In
general, while there's an extra packet back and forth because Kerberos /
GSSAPI is set up on the client / Windows side, once the server says it
doesn't support GSSENC, libpq should try a non-GSSENC connection right
away..

I'm wondering if the server DOES say it supports GSSENC, and the delay
is involved in the two sides not realizing they aren't talking to the
same Kerberos/AD servers, or something like that.

regards, tom lane

It's not enabled in my pg_hba.conf which I've attached...

On Thu, 25 Feb 2021 at 19:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Richard Crampton <rich.crampton@gmail.com> writes:

It's not enabled in my pg_hba.conf which I've attached...

pg_hba.conf has zero to do with this. That's only an after-the-fact
filter, besides which you haven't actually forbidden gssenc there.

The important questions are (1) was the server built with --with-gssapi
(probably, if your client was); (2) is a Kerberos ticket available
to the server? If so, it will be willing to engage in a gss negotiation
with the client. Given the data you've provided so far, it seems
highly likely that (1) and (2) are true, since as Stephen says the
case where gss is immediately rejected shouldn't take long.

I think it's nearly certain that the problem is not really PG's, but
reflects some sort of issue in your Kerberos/AD infrastructure.
We don't have enough info to speculate about exactly what, though.

regards, tom lane

Ok, thanks for the feedback. If you don't think it's a PG bug then I guess
we can leave it here.

Given the issue I would have expected more users to have reported a problem
so perhaps it could be my specific setup.

Regards,
Richard

On Thu, 25 Feb 2021, 20:24 Tom Lane, <tgl@sss.pgh.pa.us> wrote:

Richard Crampton <rich.crampton@gmail.com> writes:

I just upgraded to libpq=13.1 with no change in result. Is there anything
newer? I'm not sure whether it's relevant but my krb5 version is 1.17.1
and I can't upgrade this without breaking dependencies.

There were several GSSENC bugs fixed in this month's PG releases
(13.2 and 12.6). While I don't think any of them would explain this
symptom, I'd still recommend an update if you intend to rely on GSS
encryption.

Don't know anything about the bug history on the kerberos side,
but 1.17.1 isn't hugely old so I'd guess you're okay there.

regards, tom lane