Re: Protocol problem with GSSAPI encryption?
От | Andrew Gierth |
---|---|
Тема | Re: Protocol problem with GSSAPI encryption? |
Дата | |
Msg-id | 87eewyc1np.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Protocol problem with GSSAPI encryption? (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Protocol problem with GSSAPI encryption?
|
Список | pgsql-hackers |
>>>>> "Bruce" == Bruce Momjian <bruce@momjian.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)
В списке pgsql-hackers по дате отправления: