Re: Direct SSL connection and ALPN loose ends

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Direct SSL connection and ALPN loose ends
Date: 2024-06-20 23:13:05
Message-ID: 03853f1b-19c4-4ab8-b934-c18c0406de1e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20/06/2024 20:02, Jacob Champion wrote:
> On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>>> I think the behavior with v2 and v3 errors should be the same. And I
>>> think an immediate failure is appropriate on any v2/v3 error during
>>> negotiation, assuming we don't use those errors for things like "TLS not
>>> supported", which would warrant a fallback.
>>
>> For GSS encryption, it was my vague understanding that older servers
>> respond with an error rather than the "not supported" indication. For
>> TLS, though, the decision in a49fbaaf (immediate failure) seemed
>> reasonable.
>
> Would an open item for this be appropriate?

Added.

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

>> I think the behavior with v2 and v3 errors should be the same. And I
>> think an immediate failure is appropriate on any v2/v3 error during
>> negotiation, assuming we don't use those errors for things like "TLS not
>> supported", which would warrant a fallback.
>
> For GSS encryption, it was my vague understanding that older servers
> respond with an error rather than the "not supported" indication. For
> TLS, though, the decision in a49fbaaf (immediate failure) seemed
> reasonable.

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.

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-06-20 23:13:15 Re: Pluggable cumulative statistics
Previous Message Tom Lane 2024-06-20 23:12:22 Re: Failures in constraints regression test, "read only 0 of 8192 bytes"