Re: Experiments with Postgres and SSL

Greg Stark <stark@mit.edu>

From: Greg Stark <stark@mit.edu>
To: Andrey Borodin <amborodin86@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-01-19T17:07:41Z
Lists: pgsql-hackers
On Thu, 19 Jan 2023 at 00:45, Andrey Borodin <amborodin86@gmail.com> wrote:

> But..do we have to treat any unknown start sequence of bytes as a TLS
> connection? Or is there some definite subset of possible first bytes
> that clearly indicates that this is a TLS connection or not?

Absolutely not, there's only one MessageType that can initiate a
connection, ClientHello, so the initial byte has to be a specific
value. (0x16)

And probably to implement HTTP/Websocket it would probably only peek
at the first byte and check for things like G(ET) and H(EAD) and so
on, possibly only over SSL but in theory it could be over any
connection if the request comes before the startup packet.

Personally I'm motivated by wanting to implement status and monitoring
data for things like Prometheus and the like. For that it would just
be simple GET queries to recognize. But tunneling pg wire protocol
over websockets sounds cool but not really something I know a lot
about. I note that Neon is doing something similar with a proxy:
https://neon.tech/blog/serverless-driver-for-postgres


--
greg



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.