On Sat, 11 May 2024 at 15:36, AJ ONeal <coola...@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 default anyway), 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 unverified TLS takes the user down a > path that's just more difficult to begin with (it's easier to get a valid TLS > cert than it 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 configure an 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 the user 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
