MIME-Version: 1.0
References: <ZiH7vHwEJeRKHlST@paquier.xyz> <c786e226-4039-4522-ba07-92501fce9b6a@iki.fi>
 <CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com> <a0983295-67ae-487e-84e3-6e1148af3a25@iki.fi>
In-Reply-To: <a0983295-67ae-487e-84e3-6e1148af3a25@iki.fi>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Tue, 23 Apr 2024 10:02:10 -0700
Message-ID: <CAOYmi+nv2wc+FzpSUsTQt=-hKgP9zmvXw2fbX57CbrL7SLYz-w@mail.gmail.com>
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Michael Paquier <michael@paquier.xyz>, 
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2Bnv2wc%2BFzpSUsTQt%3D-hKgP9zmvXw2fbX57CbrL7SLYz-w%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 19, 2024 at 2:43=E2=80=AFPM Heikki Linnakangas <hlinnaka@iki.fi=
> wrote:
>
> On 19/04/2024 19:48, Jacob Champion wrote:
> > On Fri, Apr 19, 2024 at 6:56=E2=80=AFAM Heikki Linnakangas <hlinnaka@ik=
i.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.

Yes, the client should also reject, but that's not what I'm referring
to above. The server needs to fail the TLS handshake itself with the
proper error code (I think it's `no_application_protocol`?); otherwise
a client implementing a different protocol could consume the
application-level bytes coming back from the server and act on them.
That's the protocol confusion attack from ALPACA we're trying to
avoid.

> > 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=3Drequire. 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.

Oh. That's actually disappointing, since gssencmode=3Dprefer is the
default. A question I had in the original thread was, what's the
rationale behind a "require direct ssl" option that doesn't actually
require it?

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

If you're using SCRAM to authenticate the server, as opposed to just a
really strong password auth, then it really helps an analysis of the
security to know that there are no plaintext bytes that have been
interpreted by the client. This came up briefly in the conversations
that led to commit d0f4824a.

To be fair, it's a more academic concern at the moment; my imagination
can only come up with problems for SCRAM-based TLS that would also be
vulnerabilities for standard certificate-based TLS. But whether or not
it's an advantage for the code today is also kind of orthogonal to my
point. The security argument of direct SSL mode is that it reduces
risk for the system as a whole, even in the face of future code
changes or regressions. If you can't force its use, you're not
reducing that risk very much. (If anything, a "require" option that
doesn't actually require it makes the analysis more complicated, not
less...)

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

Hm. For some reason I thought it was easier the other direction, but I
can't remember why I thought that. I'll withdraw the comment for now
:)

--Jacob