On 29/04/2024 21:04, Jacob Champion wrote:
> On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas <hlinnaka@iki.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.
Yes, and that is what we want, right? If the client uses old negotiation
style, and includes ALPN in its ClientHello, but requests protocol
"noodles" instead of "postgresql", it seems good to reject the connection.
Note that if the client does not request ALPN at all, the callback is
not called, and the connection is accepted. Old clients still work
because they do not request ALPN.
>> 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!
--
Heikki Linnakangas
Neon (https://neon.tech)
