From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Dave Cramer <davecramer(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question about error message in auth.c |
Date: | 2023-05-25 00:15:34 |
Message-ID: | ZG6oppOMgMYijaG8@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 24, 2023 at 02:12:23PM -0400, Dave Cramer wrote:
> The last piece of information is the encryption state. However when an SSL
> connection fails to authenticate the state is not encrypted.
>
> When would it ever be encrypted if authentication fails ?
I am not sure to follow. Under a SSL connection things should be
encrypted. Or perhaps that's something related to hostssl and/or
hostnossl?
Back to the point, the SSL handshake happens before any authentication
attempt and any HBA resolution, so a connection could be encrypted
before authentication gets rejected. The error path you are pointing
at would happen after the SSL handshake is done. For instance, take
an HBA entry like that:
# TYPE DATABASE USER ADDRESS METHOD
host all all 127.0.0.1/32 reject
Then, attempting a connection with sslmode=prefer, one can see the
difference:
$ psql -h 127.0.0.1 -d postgres -U postgres
psql: error: connection to server at "127.0.0.1", port 5432 failed:
FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL encryption
connection to server at "127.0.0.1", port 5432 failed: FATAL:
pg_hba.conf rejects connection for host "127.0.0.1", user "postgres",
database "postgres", no encryption
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-05-25 00:34:38 | Re: Proposal: Removing 32 bit support starting from PG17++ |
Previous Message | Thomas Munro | 2023-05-25 00:09:36 | Re: Proposal: Removing 32 bit support starting from PG17++ |