Re: Direct SSL connection with ALPN and HBA rules
От | Robert Haas |
---|---|
Тема | Re: Direct SSL connection with ALPN and HBA rules |
Дата | |
Msg-id | CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Direct SSL connection with ALPN and HBA rules (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: Direct SSL connection with ALPN and HBA rules
(Jacob Champion <jacob.champion@enterprisedb.com>)
|
Список | pgsql-hackers |
On Tue, Apr 23, 2024 at 1:22 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote: > > > On 22/04/2024 10:19, Michael Paquier wrote: > > >> As a whole, I can get behind a unique GUC that forces the use of > > >> direct. Or, we could extend the existing "ssl" GUC with a new > > >> "direct" value to accept only direct connections and restrict the > > >> original protocol (and a new "postgres" for the pre-16 protocol, > > >> rejecting direct?), while "on" is able to accept both. > > > > > > I'd be OK with that, although I still don't really see the point of forcing > > > this from the server side. We could also add this later. > > > > I'd be OK with doing something only in v18, if need be. Jacob, what > > do you think? > > I think it would be nice to have an option like that. Whether it's > done now or in 18, I don't have a strong opinion about. But I do think > it'd be helpful to have a consensus on whether or not this is a > security improvement, or a performance enhancement only, before adding > said option. As it's implemented, if the requiredirect option doesn't > actually requiredirect, I think it looks like security but isn't > really. I've not followed this thread closely enough to understand the comment about requiredirect maybe not actually requiring direct, but if that were true it seems like it might be concerning. But as far as having a GUC to force direct SSL or not, I agree that's a good idea, and that it's better than only being able to control the behavior through pg_hba.conf, because it removes room for any possible doubt about whether you're really enforcing the behavior you want to be enforcing. It might also mean that the connection can be rejected earlier in the handshaking process on the basis of the GUC value, which could conceivably prevent a client from reaching some piece of code that turns out to have a security vulnerability. For example, if we found out that direct SSL connections let you take over the Pentagon before reaching the authentication stage, but for some reason regular connections don't have the same problem, being able to categorically shut off direct SSL would be valuable. However, I don't really see why this has to be done for this release. It seems like a separate feature from direct SSL itself. If direct SSL hadn't been committed at the very last minute, then it would have been great if this had been done for this release, too. But it was. The moral we ought to take from that is "perhaps get the big features in a bit further in advance of the freeze," not "well we'll just keep hacking after the freeze." -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Jacob ChampionДата:
Сообщение: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs