Re: Question about error message in auth.c

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

In response to

Browse pgsql-hackers by date

  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++