Re: Direct SSL connection and ALPN loose ends
От | Heikki Linnakangas |
---|---|
Тема | Re: Direct SSL connection and ALPN loose ends |
Дата | |
Msg-id | 03853f1b-19c4-4ab8-b934-c18c0406de1e@iki.fi обсуждение исходный текст |
Ответ на | Re: Direct SSL connection and ALPN loose ends (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: Direct SSL connection and ALPN loose ends
|
Список | pgsql-hackers |
On 20/06/2024 20:02, Jacob Champion wrote: > On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion > <jacob.champion@enterprisedb.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)
В списке pgsql-hackers по дате отправления: