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