MIME-Version: 1.0
References: <27b29a35-9b96-46a9-bc1a-914140869dac@gmail.com>
 <CAOYmi+=tX4a_eXU5bhj+z7w0ZkZ-EAQ9YLYSnoGxjmdFw8AHxA@mail.gmail.com>
 <CAGECzQQeq5ze1XBwhb+hbqoOicv5W95GanHA6=x1YG_mnbZyww@mail.gmail.com>
 <CAOYmi+=q0vsu=aBJhg95NAE1d562-rBfV5TuyohSoj_0n6+fjg@mail.gmail.com> <CAFY6G8ddn=i4bv4q6KGgw0U+SqeFUiavOXR9ja8S1VHyfBW-+Q@mail.gmail.com>
In-Reply-To: <CAFY6G8ddn=i4bv4q6KGgw0U+SqeFUiavOXR9ja8S1VHyfBW-+Q@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 12 Dec 2024 08:44:33 -0800
Message-ID: <CAOYmi+mvL-yTCdaB3wsRsQMwRcmNDCRXj_TrPUaV-HBMucCNgQ@mail.gmail.com>
Subject: Re: SCRAM pass-through authentication for postgres_fdw
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, 
	PostgreSQL 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%2BmvL-yTCdaB3wsRsQMwRcmNDCRXj_TrPUaV-HBMucCNgQ%40mail.gmail.com>
Precedence: bulk

On Wed, Dec 11, 2024 at 11:04=E2=80=AFAM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> Em qua., 4 de dez. de 2024 =C3=A0s 20:39, Jacob Champion
> <jacob.champion@enterprisedb.com> escreveu:
> > Sure, I'm not saying it's worse than plaintext. But a third
> > alternative might be actual pass-through SCRAM [1], where either you
> > expect the two servers to share a certificate fingerprint, or
> > explicitly disable channel bindings on the second authentication pass
> > in order to allow the MITM. (Or, throwing spaghetti, maybe even have
> > the primary server communicate the backend cert so you can verify it
> > and use it in the binding?)
>
> I'm not understanding how these options would work for this scenario.
> I understand your concern about making the users copying the SCRAM
> verifiers around but I don't understand how this third alternative fix
> this issue. Would it be something similar to what you've implemented on
> [1]?

Yeah, I was speaking in reference to my LDAP/SCRAM patchset from a
while back. (I'm just going to call that approach "proxied SCRAM" for
now.)

> The approach on this patch is that when the backend open the
> connection with the foreign server, it will use the ClientKey stored
> from the first client connection with the backend to build the final
> client message that will be sent to the foreign server, which was
> created/validated based on verifiers of the first backend. I can't see
> how the foreign server can validate the client proof without having
> the identical verifiers with the first backend.

Correct. The only way this strategy will work is if the verifiers are
the same. (Proxied SCRAM allows for different verifiers -- with
different salts and/or iterations -- with the same password.)

I do like that the action "copy the verifier" is a pretty clear signal
that you want the servers to be able to MITM each other. It's less
attack surface than having the two servers share a certificate, for
sure, and less work than communicating a new binding. Only users that
have opted into that are "vulnerable".

> I tested a scenario where the client open a connection with the
> backend using channel binding and the backend open a connection with
> the foreign server also using channel binding and everything seems to
> works fine. I don't know if I missing something here, but here is how
> I've tested this:

All that looks good. Sorry, I hadn't intended to derail your
particular proposal with that -- the channel binding problem only
shows up with my proxied SCRAM, because the client has to decide which
tls-server-end-point to trust and put into the binding.

(It's important that your patchset works with channel bindings too, of
course, but I don't expect that to be a problem. It shouldn't matter
to this approach.)

--Jacob