Re: Experiments with Postgres and SSL

Jacob Champion <jchampion@timescale.com>

From: Jacob Champion <jchampion@timescale.com>
To: Greg Stark <stark@mit.edu>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-02-28T19:02:42Z
Lists: pgsql-hackers
On Tue, Feb 28, 2023 at 10:33 AM Greg Stark <stark@mit.edu> wrote:
> On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > Good idea. Do we want to just require the protocol to be "postgres", or
> > perhaps "postgres/3.0"? Need to register that with IANA, I guess.
>
> I had never heard of this before, it does seem useful. But if I
> understand it right it's entirely independent of this patch.

It can be. If you want to use it in the strongest possible way,
though, you'd have to require its use by clients. Introducing that
requirement later would break existing ones, so I think it makes sense
to do it at the same time as the initial implementation, if there's
interest.

> We can
> add it to all our Client/Server exchanges whether they're the initial
> direct SSL connection or the STARTTLS negotiation?

I'm not sure it would buy you anything during the STARTTLS-style
opening. You already know what protocol you're speaking in that case.
(So with the ALPACA example, the damage is already done.)

Thanks,
--Jacob



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Enhance libpq encryption negotiation tests with new GUC

  2. With gssencmode='require', check credential cache before connecting

  3. Add tests for libpq gssencmode and sslmode options

  4. Move Kerberos module

  5. Give nicer error message when connecting to a v10 server requiring SCRAM.