On 05/17/21 16:35, Magnus Hagander wrote: > So you're saying that some entries int he parameter section would > depend on the db/user/ip combo and some would depend just on the ip?
I don't *think* that's what I was saying. What I was thinking was this: The pg_hba.conf file is an ordered list of entries. Each entry can specify a (broad or narrow) set of IPs it applies to, a (broad or narrow) set of databases it applies to, and a (broad or narrow) set of users it applies to. Also, in this hypothetical, it can specify a min protocol version. Right now, we're doing something like this: 1. accept an incoming connection, learning the client IP 2. SSLRequest message leads to negotiating TLS 3. StartupMessage supplies the desired database and user name 4. pg_hba entries are consulted once and filtered down to the first one applicable to the client IP, database, and username (and SSLness) 5. that entry is used for authentication I suggested only: Insert step 1½, filter the pg_hba entries down to only those that could possibly accept a connection from this IP address. This is an improper subset of the whole list, and an improper superset of the singleton to be generated later in step 4. Step 2 still negotiates TLS, but can fail early if the protocol would be older than the oldest allowed in the pre-filtered list. Step 4 takes that pre-filtered list and completes the restriction down to first entry matching the IP, database, and username. This should be the same singleton it would generate now. But it can fail-fast if that entry would require a higher protocol version than what's been negotiated, before sending the corresponding authentication request message, so no authentication data will be exchanged over a less-secure channel than intended. However, the user, database name, and options in the Startup message might have been exposed over a lower TLS version than intended. Maybe that's not the end of the world? Regards, -Chap
