On Sat, 11 May 2024 at 15:36, AJ ONeal <coolaj86@proton.me> wrote:
> Having postgres TLS/SNI/ALPN routable by default will just be more intuitive (it's what I assumed would have been the
defaultanyway), and help increase adoption in cloud, enterprise, and other settings.
Routing is primarily a feature for "cloud-first" deployments. I.e.
things like Kubernetes or equivalent. I don't think people deploying
to their own metal or on their own network often need this kind of
feature today. Of course we don't know what the future holds and it
could well become more common.
In that context I think it's clear that user-oriented tools like psql
shouldn't change their default behaviour. They need the maximum
flexibility of being able to negotiate plain text and GSSAUTH
connections if possible. It's only applications deployed by the same
cloud environment building tools that deploy the database and SSL
proxies that will know where direct SSL connections are necessary.
> We live in the world of ACME / Let's Encrypt / ZeroSSL. Many proxies have that built in. As such optimizing for
unverifiedTLS takes the user down a path that's just more difficult to begin with (it's easier to get a valid TLS cert
thanit is to get a self-signed cert these days), and more nuanced (upcoming implementors are accustomed to TLS being
verified).It's easy to document how to use the letsencrypt client with postgres. It will also be increasingly easy to
configurean ACME-enable proxy for postgres and not worry about it in the server at all.
I tend to agree that it would be good for our documentation and
install scripts to assume letsencrypt certs can be requested. That
said there are still a lot of database environments that are not on
networks that can reach internet services directly without special
firewall or routing rules set up.
> Allow the user to specify ALPN
>
> I don't think this is particularly controversial or nuanced, so I don't have much to say here - most TLS tools allow
theuser to specify ALPN for the same reason they allow specifying the port number - either for privacy,
security-by-obscurity,or navigating some form of application or user routing.
I think I need a citation before I believe this. I can't imagine it
makes sense for anything other than general purpose TLS testing tools
to allow arbitrary protocol names. It seems like something that would
be mostly useful for pentesting or regression tests. But for actual
deployed applications it doesn't make any sense to me.
--
greg