Re: Direct SSL connection with ALPN and HBA rules

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Date: 2024-04-23 07:07:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Apr 23, 2024 at 01:48:04AM +0300, Heikki Linnakangas wrote:
> Here's the patch for that. The error message is:
> "direct SSL connection was established without ALPN protocol negotiation
> extension"


> That's accurate, but I wonder if we could make it more useful to a user
> who's wondering what went wrong. I'd imagine that if the server doesn't
> support ALPN, it's because you have some kind of a (not necessarily
> malicious) generic SSL man-in-the-middle that doesn't support it. Or you're
> trying to connect to an HTTPS server. Suggestions welcome.

Hmm. Is there any point in calling SSL_get0_alpn_selected() in
open_client_SSL() to get the ALPN if current_enc_method is not

In the documentation of PQsslAttribute(), it is mentioned that empty
string is returned for "alpn" if ALPN was not used, however the code
returns NULL in this case:
SSL_get0_alpn_selected(conn->ssl, &data, &len);
if (data == NULL || len == 0 || len > sizeof(alpn_str) - 1)
return NULL;

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2024-04-23 08:18:15 Re: pg_stat_statements and "IN" conditions
Previous Message kuroda.keisuke 2024-04-23 06:44:00 Add privileges test for pg_stat_statements to improve coverage