On 19/04/2024 08:06, Michael Paquier wrote:
Hi all, (Heikki in CC.)
(Adding Jacob)
Since 91044ae4baea (require ALPN for direct SSL connections) and d39a49c1e459 (direct hanshake), direct SSL connections are supported (yeah!), still the thread where this has been discussed does not cover the potential impact on HBA rules: https://www.postgresql.org/message-id/CAM-w4HOEAzxyY01ZKOj-iq%3DM4-VDk%3DvzQgUsuqiTFjFDZaebdg%40mail.gmail.com My point is, would there be a point in being able to enforce that ALPN is used from the server rather than just relying on the client-side sslnegotiation to decide if direct SSL connections should be forced or not? Hence, I'd imagine that we could have an HBA option for hostssl rules, like a negotiation={direct,postgres,all} that cross-checks Port->alpn_used with the option value in a hostssl entry, rejecting the use of connections using direct connections or the default protocol if these are not used, giving users a way to avoid one. As this is a new thing, there may be an argument in this option for security reasons, as well, so as it would be possible for operators to turn that off in the server.
I don't think ALPN gives any meaningful security benefit, when used with the traditional 'postgres' SSL negotiation. There's little possibility of mixing that up with some other protocol, so I don't see any need to enforce it from server side. This was briefly discussed on that original thread [1]. With direct SSL negotiation, we always require ALPN.
I don't see direct SSL negotiation as a security feature. Rather, the point is to reduce connection latency by saving one round-trip. For example, if gssencmode=prefer, but the server refuses GSS encryption, it seems fine to continue with negotiated SSL, instead of establishing a new connection with direct SSL. What would be the use case of requiring direct SSL in the server? What extra security do you get?
Controlling these in HBA is a bit inconvenient, because you only find out after authentication if it's allowed or not. So if e.g. direct SSL connections are disabled for a user, the client would still establish a direct SSL connection, send the startup packet, and only then get rejected. The client would not know if it was rejected because of the direct SSL or for some reason, so it needs to retry with negotiated SSL. Currently, as it is master, if the TLS layer is established with direct SSL, you never need to retry with traditional negotiation, or vice versa.
[1] https://www.postgresql.org/message-id/CAAWbhmjetCVgu9pHJFkQ4ejuXuaz2mD1oniXokRHft0usCa7Yg%40mail.gmail.com
-- Heikki Linnakangas Neon (https://neon.tech)
