Re: Direct SSL connection with ALPN and HBA rules

On 19/04/2024 19:48, Jacob Champion wrote:
> On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> 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].)

Ah, good catch, that fell through the cracks. Agreed, the client should
reject a direct SSL connection if the server didn't send ALPN. I'll add
that to the Open Items so we don't forget again.

>> 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?)

To disable sending the startup packet in plaintext, you need to use
sslmode=require. Same as before the patch. GSS is still allowed, as it
takes precedence over SSL if both are enabled in libpq. Per the docs:

> Note that if gssencmode is set to prefer, a GSS connection is
> attempted first. If the server rejects GSS encryption, SSL is
> negotiated over the same TCP connection using the traditional
> postgres protocol, regardless of sslnegotiation. In other words, the
> direct SSL handshake is not used, if a TCP connection has already
> been established and can be used for the SSL handshake.

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

Can you elaborate on the more advanced uses of SCRAM?

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

Forcing it to be enabled piecemeal based on role or database has similar
problems. Forcing it enabled for all connections seems sensible, though.
Forcing it enabled based on the client's source IP address, but not
user/database would be somewhat sensible too, but we don't currently
have the HBA code to check the source IP and accept/reject SSLRequest
based on that. The HBA rejection always happens after the client has
sent the startup packet.

--
Heikki Linnakangas
Neon (https://neon.tech)