Re: SCRAM pass-through authentication for postgres_fdw

On Wed, Dec 11, 2024 at 11:04 AM Matheus Alcantara
<matheusssilv97(at)gmail(dot)com> wrote:
> Em qua., 4 de dez. de 2024 às 20:39, Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)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