Re: Protocol problem with GSSAPI encryption?

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Protocol problem with GSSAPI encryption?
Date: 2019-12-02 16:06:30
Message-ID: cc586c62-907a-9dae-8930-9b8239bbd2c0@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-12-01 02:13, Andrew Gierth wrote:
> But ProcessStartupPacket assumes that the packet after a failed
> negotiation of either kind will be the actual startup packet, so the SSL
> connection request is rejected with "unsupported version 1234.5679".
>
> I'm guessing this usually goes unnoticed because most people are
> probably not set up to do GSSAPI, and those who are are probably ok with
> using it for encryption. But if the client is set up for GSSAPI and the
> server not, then trying to do an SSL connection will fail when it should
> succeed, and PGGSSENCMODE=disable in the environment (or connect string)
> is necessary to get the connection to succeed.
>
> It seems to me that this is a bug in ProcessStartupPacket, which should
> accept both GSS or SSL negotiation requests on a connection (in either
> order). Maybe secure_done should be two flags rather than one?

I have also seen reports of that. I think your analysis is correct.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-02 16:23:32 Windows buildfarm members vs. new async-notify isolation test
Previous Message Alvaro Herrera 2019-12-02 15:56:08 Re: Using XLogFileNameP in critical section