Re: Direct SSL connection with ALPN and HBA rules

On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 19/04/2024 08:06, Michael Paquier wrote:
> > 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?

I'm a little confused about whether we're talking about requiring ALPN
or requiring direct connections. I think you mean the latter, Michael?

Personally, I was hoping that we'd have a postgresql.conf option to
reject every network connection that wasn't direct SSL, but I ran out
of time to review the patchset for 17. I would like to see server-side
enforcement of direct SSL in some way, eventually. I hadn't given much
thought to HBA, though.

> 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].

Agreed. By the time you've issued a traditional SSL startup packet,
and the server responds with a go-ahead, it's pretty much understood
what protocol is in use.

> With direct SSL negotiation, we always require ALPN.

(As an aside: I haven't gotten to test the version of the patch that
made it into 17 yet, but from a quick glance it looks like we're not
rejecting mismatched ALPN during the handshake as noted in [1].)

> I don't see direct SSL negotiation as a security feature.

`direct` mode is not, since it's opportunistic, but I think people are
going to use `requiredirect` as a security feature. At least, I was
hoping to do that myself...

> 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.

Well, assuming the user is okay with plaintext negotiation at all.
(Was that fixed before the patch went in? Is GSS negotiation still
allowed even with requiredirect?)

> What would be the use case of requiring
> direct SSL in the server? What extra security do you get?

You get protection against attacks that could have otherwise happened
during the plaintext portion of the handshake. That has architectural
implications for more advanced uses of SCRAM, and it should prevent
any repeats of CVE-2021-23222/23214. And if the peer doesn't pass the
TLS handshake, they can't send you anything that you might forget is
untrusted (like, say, an error message).

> 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,

Hopefully disabling direct SSL piecemeal is not a desired use case?
I'm not sure it makes sense to focus on that. Forcing it to be enabled
shouldn't have the same problem, should it?

--Jacob

[1] https://www.postgresql.org/message-id/CAOYmi%2B%3DcnV-8V8TndSkEF6Htqa7qHQUL_KnQU8-DrT0Jjnm3_Q%40mail.gmail.com