Re: Direct SSL connection with ALPN and HBA rules

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)