Frontend/Backend Protocol: SSL / GSS Protocol Negotiation Problem
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t41626psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 03:21 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t41626_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t41626_1 && git checkout t41626_1Patchset v1 (message #1) is on t41626_1
Hi!
I've received a bug report from a PostgreSQL user that psql 12.1 failed to connect to a PostgreSQL 12.1 server, with the following error message:
psql: error: could not connect to server: FATAL: unsupported frontend protocol 1234.5679: server supports 2.0 to 3.0
After inspecting a TCP dump, I realised that libpq apparently sent a GSS startup packet, got 'N' (not supported) response, then tried a SSL startup packet, at which point the server sent an error.
The bug report is available at the following URL:
https://github.com/PostgresApp/PostgresApp/issues/537
After inspecting postmaster.c, it seems that postmaster only allows a single negotiation attempt, but libpq doesn't know that.
I'm not familiar with GSS, but from my naive point of view it would seem that we should fix this issue as follows:
1) On the server side, allow multiple negotiation attempts (eg. allow SSL negotiation after a rejected GSS negotiation attempt)
2) On the client side, detect an error message after the second negotiation attempt, and reconnect, to ensure compatibility with servers that do not support multiple attempts yet.
I've attached two proposed patches with these changes.
Best regards,
Jakob
Attachments:
t41626_10001-Allow-multiple-ssl-gss-negotiation-attempts.patchapplication/octet-stream; name=0001-Allow-multiple-ssl-gss-negotiation-attempts.patch; x-unix-mode=0644Download+25-12
0002-libpq-Retry-after-failed-ssl-gss-negotiation.patchapplication/octet-stream; name=0002-libpq-Retry-after-failed-ssl-gss-negotiation.patch; x-unix-mode=0644Download+61-29
On Fri, Dec 06, 2019 at 02:25:46PM +0100, Jakob Egger wrote:
I've received a bug report from a PostgreSQL user that psql 12.1
failed to connect to a PostgreSQL 12.1 server, with the following
error message:psql: error: could not connect to server: FATAL: unsupported
frontend protocol 1234.5679: server supports 2.0 to 3.0
Andrew Gierth has reported this issue, and has provided a patch:
/messages/by-id/87h82kzwqn.fsf@news-spur.riddles.org.uk
If you could help with it, that would be great.
--
Michael
On 6. Dec 2019, at 15:08, Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Dec 06, 2019 at 02:25:46PM +0100, Jakob Egger wrote:
I've received a bug report from a PostgreSQL user that psql 12.1
failed to connect to a PostgreSQL 12.1 server, with the following
error message:psql: error: could not connect to server: FATAL: unsupported
frontend protocol 1234.5679: server supports 2.0 to 3.0Andrew Gierth has reported this issue, and has provided a patch:
/messages/by-id/87h82kzwqn.fsf@news-spur.riddles.org.uk
If you could help with it, that would be great.
--
Michael
Thanks for pointing me to the right thread! My server side fix is similar to Andrews, but Andrews is maybe a bit more elegant.
But this also needs to be fixed on the client side as well, otherwise affected clients can't connect to older servers anymore.
My second patch attempts to fix the issue on the client side.
I'll respond to the other thread as well.
Jakob
"Jakob" == Jakob Egger <jakob@eggerapps.at> writes:
Jakob> But this also needs to be fixed on the client side as well,
Jakob> otherwise affected clients can't connect to older servers
Jakob> anymore.
There's a workaround, which is to set PGGSSENCMODE=disable on the
client.
It would be far better to avoid complicating the client side with this
if we can possibly do so.
--
Andrew (irc:RhodiumToad)
On 6. Dec 2019, at 16:45, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
"Jakob" == Jakob Egger <jakob@eggerapps.at> writes:
Jakob> But this also needs to be fixed on the client side as well,
Jakob> otherwise affected clients can't connect to older servers
Jakob> anymore.There's a workaround, which is to set PGGSSENCMODE=disable on the
client.It would be far better to avoid complicating the client side with this
if we can possibly do so.
As far as I understand, the bug impacts clients version 12.0 or later who have Kerberos when connecting to 12.0 or 12.1 servers that don't have Kerberos. (Assuming that the bug will be fixed server side in 12.2)
I don't know how many people use Kerberos, so I can't say if it's worth the additional complexiity to work around the bug.
In any case, the workaround should probably be documented somewhere:
If you try to connect to a PostgreSQL 12.0 or 12.1 server and you get the following error message:
psql: error: could not connect to server: FATAL: unsupported frontend protocol 1234.5679: server supports 2.0 to 3.0
Then you need to use the connection parameter gssencmode=disable
Is there a place where such workarounds are documented, or do we rely on Google indexing the mailing list archive?
Best regards,
Jakob