Re: SCRAM pass-through authentication for postgres_fdw - Mailing list pgsql-hackers
From | Matheus Alcantara |
---|---|
Subject | Re: SCRAM pass-through authentication for postgres_fdw |
Date | |
Msg-id | CAFY6G8ddn=i4bv4q6KGgw0U+SqeFUiavOXR9ja8S1VHyfBW-+Q@mail.gmail.com Whole thread Raw |
In response to | Re: SCRAM pass-through authentication for postgres_fdw (Jacob Champion <jacob.champion@enterprisedb.com>) |
Responses |
Re: SCRAM pass-through authentication for postgres_fdw
|
List | pgsql-hackers |
Em qua., 4 de dez. de 2024 às 20:39, Jacob Champion <jacob.champion@enterprisedb.com> escreveu: > > On Wed, Dec 4, 2024 at 3:05 PM 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=openssl ... - Start two Postgresql servers - Configure to use ssl on both servers ssl = on ssl_cert_file = '/path/to/server.crt' ssl_key_file = '/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=require psql "host=127.0.0.1 dbname=local sslmode=require channel_binding=require" - 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-59d423071525%40timescale.com [2] src/backend/libpq/auth-scram.c#read_client_final_message -- Matheus Alcantara EDB: https://www.enterprisedb.com
pgsql-hackers by date: