Re: Direct SSL connection and ALPN loose ends - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Direct SSL connection and ALPN loose ends
Date
Msg-id CAOYmi+khV8Bg4EhnRt=EoMkktOsDtbzRRCjUfRoDzzK4LkV4ZQ@mail.gmail.com
Whole thread Raw
In response to Re: Direct SSL connection and ALPN loose ends  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Direct SSL connection and ALPN loose ends
Re: Direct SSL connection and ALPN loose ends
List pgsql-hackers
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > By "negotiation" I mean the server's response to the startup packet.
> > I.e. "supported"/"not supported"/"error".
>
> Ok, I'm still a little confused, probably a terminology issue. The
> server doesn't respond with "supported" or "not supported" to the
> startup packet, that happens earlier. I think you mean the SSLRequst /
> GSSRequest packet, which is sent *before* the startup packet?

Yes, sorry. (I'm used to referring to those as startup packets too, ha.)

> Hmm, right, GSS encryption was introduced in v12, and older versions
> respond with an error to a GSSRequest.
>
> We probably could make the same assumption for GSS as we did for TLS in
> a49fbaaf, i.e. that an error means that something's wrong with the
> server, rather than that it's just very old and doesn't support GSS. But
> the case for that is a lot weaker case than with TLS. There are still
> pre-v12 servers out there in the wild.

Right. Since we default to gssencmode=prefer, if you have Kerberos
creds in your environment, I think this could potentially break
existing software that connects to v11 servers once you upgrade libpq.

Thanks,
--Jacob



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Next
From: Melanie Plageman
Date:
Subject: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin