From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Direct SSL connection with ALPN and HBA rules |
Date: | 2024-04-29 18:04:41 |
Message-ID: | CAOYmi+n2q8rxv9vUirMemMNhiQTRWbSGJpWFO4biQ9FKTrLMXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I finally understood what you mean. So if the client supports ALPN, but
> the list of protocols that it provides does not include 'postgresql',
> the server should reject the connection with 'no_applicaton_protocol'
> alert.
Right. (And additionally, we reject clients that don't advertise ALPN
over direct SSL, also during the TLS handshake.)
> The attached patch makes that change. I used the alpn_cb() function in
> openssl's own s_server program as example for that.
This patch as written will apply the new requirement to the old
negotiation style, though, won't it? My test suite sees a bunch of
failures with that.
> Unfortunately the error message you got in the client with that was
> horrible (I modified the server to not accept the 'postgresql' protocol):
>
> psql "dbname=postgres sslmode=require host=localhost"
> psql: error: connection to server at "localhost" (::1), port 5432
> failed: SSL error: SSL error code 167773280
<long sigh>
I filed a bug upstream [1].
Thanks,
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2024-04-29 18:06:52 | Re: Direct SSL connection and ALPN loose ends |
Previous Message | Alexander Lakhin | 2024-04-29 18:00:01 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |