On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > On 29/04/2024 21:43, Jacob Champion wrote: > > 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. > > Well, by that argument we don't need requiredirect/directonly at all. > This goes back to whether it's a security feature or a performance feature.
That's what I've been trying to argue, yeah. If it's not a security feature... why's it there? > There is a small benefit with sslmode=prefer if you connect to a server > that doesn't support SSL, though. With sslnegotiation=direct, if the > server rejects the direct SSL connection, the client will reconnect and > try SSL with SSLRequest. The server will respond with 'N', and the > client will proceed without encryption. sslnegotiation=directonly > removes that SSLRequest attempt, eliminating one roundtrip. Okay, agreed that in this case, there is a performance benefit. It's not enough to convince me, honestly, but are there any other cases I missed as well? > Oh I was not aware sslrootcert=system works like that. That's a bit > surprising, none of the other ssl-related settings imply or require that > SSL is actually used. For sslrootcert=system in particular, the danger of accidentally weak sslmodes is pretty high, especially for verify-ca mode. (It goes back to that other argument -- there should be, effectively, zero users who both opt in to the public CA system, and are also okay with silently falling back and not using it.) > Did we intend to set a precedence for new settings > with that? (I'll let committers answer whether they intended that or not -- I was just bringing up that we already have a setting that works like that, and I really like how it works in practice. But it's probably unsurprising that I like it.) --Jacob
