| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| 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-17 16:23:09 |
| Message-ID: | CAOYmi+kzVAaRRwxukvcKr1h=xUiHcsXhZS7E_yDtYxFwHST_XQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 17, 2024 at 8:24 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> By "negotiation", which part of the protocol are we talking about
> exactly? In the middle of the TLS handshake? After sending the startup
> packet?
By "negotiation" I mean the server's response to the startup packet.
I.e. "supported"/"not supported"/"error".
> 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.
Thanks,
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-06-17 16:24:46 | Re: Avoid orphaned objects dependencies, take 3 |
| Previous Message | Andrew Dunstan | 2024-06-17 16:21:10 | Re: RFC: adding pytest as a supported test framework |