From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Protocol problem with GSSAPI encryption? |
Date: | 2019-12-20 18:14:09 |
Message-ID: | 87eewyc1np.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Bruce" == Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> 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.
Bruce> Are you saying that there is an additional round-trip for
Bruce> starting all SSL connections because we now support GSSAPI, or
Bruce> this only happens if libpq asks for GSSAPI?
The problem only occurs if libpq thinks it might be able to do GSSAPI,
but the server does not. Without the patch I proposed or something like
it, this case fails to connect at all; with it, there will be an extra
round-trip. Explicitly disabling GSSAPI encryption in the connection
string or environment avoids the issue.
The exact condition for libpq seems to be a successful call to
gss_acquire_cred, but I'm not familiar with GSS in general.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-12-20 18:16:27 | Re: Protocol problem with GSSAPI encryption? |
Previous Message | Stephen Frost | 2019-12-20 18:07:58 | Re: Protocol problem with GSSAPI encryption? |