Zsolt Parragi <[email protected]> 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
