Feature Request: Option for TLS no SSLRequest with psql

public inbox for [email protected]  
help / color / mirror / Atom feed

From: AJ ONeal <[email protected]>
To: [email protected] <[email protected]>
Subject: Feature Request: Option for TLS no SSLRequest with psql
Date: Sat, 11 May 2024 15:19:50 +0000
Message-ID: <ECNyobMWPeoCd4yj_5J0RsDL1yKC9MbbBwOGCYHgcts7v0BW_-znGIoxcvfzUsf3yKvUB6Lef22OBMZnJyZ-0T2U1qaVflQqEGO0RFHp1PE=@proton.me> (raw)

Could we get a `postgrestls://` or `sslmode=tls` or --tls option that instructs psql to sends straight TLS, skipping the 0000000804d2162f / 0000000804d21630 + N / Y / S handshake?

Rationale:

In the age of TLS, SNI, and ALPN, protocol routing and virtual hosting is easier, more reliable, and less expensive than it's ever been, but having to deal with a bespoke protocol handshake at "the edge" really puts a damper on things:

Currently, every single proxy / TLS tool has to decide whether or not to support Postgres specifically. It's a lot of duplicate work and causes Postgres support to lag until someone who is 1) familiar with the language 2) familiar with the codebase 3) familiar with postgres' SSLRequest 4) and has power to review and accept changes is available (and willing) to help.

(re: https://github.com/mholt/caddy-l4/issues/187, https://github.com/traefik/traefik/issues/9929, https://github.com/envoyproxy/envoy/issues/2861, https://github.com/therootcompany/sclient/issues/5, and many more)

It would be great if the postgres server also supported receiving straight TLS, but since the reverse proxy / load balancer typically terminates the TLS in these settings, even if it were only available in the client, it would simplify protocol routing greatly.

Note: in many instances subdomains are used to specify user/db to route to, so SNI+ALPN alone are enough to complete the routing, but even if the plaintext user/db/app message is being matched on, it's much easier for someone to write a module in any given proxy for that because it fits the same pattern as HTTP Host matching - it doesn't require a handshake on either side of the TLS termination, which is where the complexity comes in.

AJ ONeal

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Feature Request: Option for TLS no SSLRequest with psql
  In-Reply-To: <ECNyobMWPeoCd4yj_5J0RsDL1yKC9MbbBwOGCYHgcts7v0BW_-znGIoxcvfzUsf3yKvUB6Lef22OBMZnJyZ-0T2U1qaVflQqEGO0RFHp1PE=@proton.me>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox