Re: Require SSL connection to postgres for oauth

Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> writes:

>> We would still need to consider compatibility, though. I keep hearing
>> people talk about running infrastructure within "trusted" TCP (I
>> assume via a mesh or cloud VPN of some sort?) and I don't know that
>> they should be made to use a debug flag.
>
> Is this a common-enough use case to think about? Even within a
> "trusted" infrastructure, sending passwords in cleartext seems wrong
> to me.

This case is really common, specially now that people is knowing more
and more about managing network with eBPF and using tools like Cilium.
But what really worries me more about these kind of situation it's the
reason why that exists. For example, there's some special documented
cases when you use Kubernetes that using an TLS connection may kill your
connection[1] and this happens only when TLS, this that looks like an
error is actually a mandatory requirement following the RFC9293[2], so
not having a backward compatibility will be a mistake and will lead a
lot of users to not being able to use OAuth when using more than one
psql client over the same tunnel. so I think it is a really common
situation that someone will be using Oauth without TLS

If you want to look outside the Kubernetes world, the same apply for any
cloud service providing some kind of virtual port-forward over a
websocket, which basically it's the same connection, and if you have any
kind of firewall, the connection will also get a RST which will
basically will the connection.

So yes, keeping the non-TLS connections I think it's a must.

[1] https://github.com/kubernetes/kubectl/issues/1169
[2] https://datatracker.ietf.org/doc/html/rfc9293#name-reset-generation

--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com