On Mon, Apr 29, 2024 at 1:38 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > Sure, we'd try to fix them ASAP. But we've had the SSLRequest > negotiation since time immemorial. If a new vulnerability is found, it's > unlikely that we'd need to disable the SSLRequest negotiation altogether > to fix it. We'd be in serious trouble with back-branches in that case. > There's no sudden need to have a kill-switch for it.
I'm not really arguing that you'd need the kill switch to fix a problem in the code. (At least, I'm not arguing that in this thread; I reserve the right to argue that in the future. :D) But between the point of time that a vulnerability is announced and a user has upgraded, it's really nice to have a switch as a mitigation. Even better if it's server-side, because then the DBA can protect all their clients without requiring action on their part. > Taking that to the extreme, you could argue for a kill-switch for every > feature, just in case there's a vulnerability in them. I agree that > authentication is more sensitive so reducing the surface of that is more > reasonable. And but nevertheless. I mean... that would be extreme, yeah. I don't think anyone's proposed that. > If you only > have v17 servers in your environment, so you know all servers support > direct negotiation if they support SSL at all, but a mix of servers with > and without SSL, sslnegotiation=directonly would reduce roundtrips with > sslmode=prefer. But if you're in that situation, what does the use of directonly give you over `sslnegotiation=direct`? You already know that servers support direct, so there's no additional performance penalty from the less strict mode. > Making requiredirect to imply sslmode=require, or error out unless you > also set sslmode=require, feels like a cavalier way of forcing SSL. We > should have a serious discussion on making sslmode=require the default > instead. That would be a more direct way of nudging people to use SSL. > It would cause a lot of breakage, but it would also be a big improvement > to security. > > Consider how sslnegotiation=requiredirect/directonly would feel, if we > made sslmode=require the default. If you explicitly set "sslmode=prefer" > or "sslmode=disable", it would be annoying if you would also need to > remove "sslnegotiation=requiredirect" from your connection string. That's similar to how sslrootcert=system already works. To me, it feels great, because I don't have to worry about nonsensical combinations (with the exception of GSS, which we've touched on above). libpq complains loudly if I try to shoot myself in the foot, and if I'm using sslrootcert=system then it's a pretty clear signal that I care more about security than the temporary inconvenience of editing my connection string for one weird server that doesn't use SSL for some reason. > I think the best way forward for those is something like a new > "require_proto" parameter that you suggested upthread. Perhaps call it > "encryption", with options "none", "ssl", "gss" so that you can provide > multiple options and libpq will try them in the order specified. For > example: > > encryption=none > encryption=ssl, none # like sslmode=prefer > encryption=gss > encryption=gss, ssl # try GSS first, then SSL > encryption=ssl, gss # try SSL first, then GSS > > This would make gssencmode and sslmode=disable/allow/prefer/require > settings obsolete. sslmode would stil be needed to distinguish between > verify-ca/verify-full though. But sslnegotiation would be still > orthogonal to that. I will give this some more thought. Thanks, --Jacob
