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
