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>
In-Reply-To: <CAOYmi+=q0vsu=aBJhg95NAE1d562-rBfV5TuyohSoj_0n6+fjg@mail.gmail.com>
From: Matheus Alcantara <matheusssilv97@gmail.com>
Date: Wed, 11 Dec 2024 16:04:41 -0300
Message-ID: <CAFY6G8ddn=i4bv4q6KGgw0U+SqeFUiavOXR9ja8S1VHyfBW-+Q@mail.gmail.com>
Subject: Re: SCRAM pass-through authentication for postgres_fdw
To: Jacob Champion <jacob.champion@enterprisedb.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/CAFY6G8ddn%3Di4bv4q6KGgw0U%2BSqeFUiavOXR9ja8S1VHyfBW-%2BQ%40mail.gmail.com>
Precedence: bulk

Em qua., 4 de dez. de 2024 =C3=A0s 20:39, Jacob Champion
<jacob.champion@enterprisedb.com> escreveu:
>
> On Wed, Dec 4, 2024 at 3:05=E2=80=AFPM Jelte Fennema-Nio <postgres@jeltef=
.nl> wrote:
> > I only see advantages over the
> > alternative, which is copying the plaintext password around. In case
> > of compromise of the server, only the salt+verifier has to be rotated,
> > not the actual user password.
>
> 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]?

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.

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:

- Configure build system to use openssl
    meson setup build -Dssl=3Dopenssl ...
- Start two Postgresql servers
- Configure to use ssl on both servers
    ssl =3D on
    ssl_cert_file =3D '/path/to/server.crt'
    ssl_key_file =3D '/path/to/server.key'
- Changed pg_hba to use ssl on both servers
    hostssl   all   all   127.0.0.1/32   scram-sha-256
    hostssl   all   all   ::1/128        scram-sha-256
- Performed all foreign server setup (CREATE SERVER ...)
- Connect into the backend using channel_binding=3Drequire
    psql "host=3D127.0.0.1 dbname=3Dlocal sslmode=3Drequire channel_binding=
=3Drequire"
- Execute a query on fdw server

I've also put a debug message before strcmp(channel_binding, b64_message)
[2] to ensure that channel binding is being used on both servers and I
got the log message on both servers logs.

Sorry if I misunderstood your message, I probably missed something here.

[1] https://www.postgresql.org/message-id/9129a012-0415-947e-a68e-59d423071=
525%40timescale.com
[2] src/backend/libpq/auth-scram.c#read_client_final_message

--=20
Matheus Alcantara
EDB: https://www.enterprisedb.com