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)