Re: Experiments with Postgres and SSL

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Experiments with Postgres and SSL
Date: 2023-02-28 19:02:42
Message-ID: CAAWbhmjetCVgu9pHJFkQ4ejuXuaz2mD1oniXokRHft0usCa7Yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 28, 2023 at 10:33 AM Greg Stark <stark(at)mit(dot)edu> wrote:
> On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-02-28 19:15:37 Re: cataloguing NOT NULL constraints
Previous Message Tomas Vondra 2023-02-28 18:55:54 Re: Memory leak from ExecutorState context?