Re: Direct SSL connection with ALPN and HBA rules - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Direct SSL connection with ALPN and HBA rules
Date
Msg-id CAGECzQS9V5t9-gNtd8pUXR+Rv1vZFE6bPYvt1bO-f+c_UkXGHw@mail.gmail.com
Whole thread Raw
In response to Re: Direct SSL connection with ALPN and HBA rules  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Direct SSL connection with ALPN and HBA rules
List pgsql-hackers
On Fri, 10 May 2024 at 15:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> New proposal:
>
> - Remove the "try both" mode completely, and rename "requiredirect" to
> just "direct". So there would be just two modes: "postgres" and
> "direct". On reflection, the automatic fallback mode doesn't seem very
> useful. It would make sense as the default, because then you would get
> the benefits automatically in most cases but still be compatible with
> old servers. But if it's not the default, you have to fiddle with libpq
> settings anyway to enable it, and then you might as well use the
> "requiredirect" mode when you know the server supports it. There isn't
> anything wrong with it as such, but given how much confusion there's
> been on how this all works, I'd prefer to cut this back to the bare
> minimum now. We can add it back in the future, and perhaps make it the
> default at the same time. This addresses points 2. and 3. above.
>
> and:
>
> - Only allow sslnegotiation=direct with sslmode=require or higher. This
> is what you, Jacob, wanted to do all along, and addresses point 1.
>
> Thoughts?

Sounds mostly good to me. But I think we'd want to automatically
increase sslmode to require if it is unset, but sslnegotation is set
to direct. Similar to how we bump sslmode to verify-full if
sslrootcert is set to system, but sslmode is unset. i.e. it seems
unnecessary/unwanted to throw an error if the connection string only
contains sslnegotiation=direct



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Inefficient nbtree behavior with row-comparison quals
Next
From: Peter Geoghegan
Date:
Subject: Re: Inefficient nbtree behavior with row-comparison quals