Skip to content

feat(postgres): Support direct SSL connections to Postgres 17+ servers #3879

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

danielfrankcom
Copy link

@danielfrankcom danielfrankcom commented May 30, 2025

This PR adds support for the sslnegotiation connection parameter which has been available since Postgres 17.0. See the libpq reference here and the 17.0 release notes.

The motivation for this setting is to allow clients to skip the Postgres-specific preample while establishing a secure connection to the server. The benefits of this are:

  • It is faster, since there are fewer messages required to set up the connection.
  • It make it easier to work with certain proxies. mitmproxy for example doesn't understand the Postgres protocol, but using a direct connection allows it to process Postgres traffic. I have seen corporate proxies that have incompatibilities with the Postgres protocol, and cause issues for clients.

Postgres 17+ servers support this option, and several other drivers support it client side. Users of sqlx can now configure the client to connect directly instead of doing the preamble. For older server versions, there is a sslnegotiation=postgres fallback which uses the traditional preamble.

As part of this change I have started including the postgresql ALPN in the client SSL handshake, since Postgres servers require it when establishing a direct connection. From my testing (and by its design) it should be ignored by servers that do not pay attention to it.

Does your PR solve an issue?

There doesn't seem to be an issue for this feature at the moment. I can create one if required. The closest I could find was #3264, but the Postgres 17 feature was just mentioned there, and the actual issue seemed to be unrelated.

I created a companion issue, fixes #3880.

Is this a breaking change?

Not as far as I can tell.

Though this feature is only supported in newer Postgres versions (17+), the default of PgSslNegotiation::Postgres maintains existing behaviour used by older library versions. This is shown by the fact that all Postgres 13 Docker integration tests pass in the GitHub workflows.

There are a few changes which could impact this, but I don't have enough context to determine if they constitute breaking changes. Please consider the following:

  • Postgres connections now set a TLS ALPN of postgresql. Servers typically ignore this (the Postgres 13 Docker integration tests show this) if they don't care about the ALPN value. It's possible in some use case the ALPN causes a server to reject the connection, but I haven't seen this in practice.
  • The build_url method now includes the sslnegotiation setting. I'm not sure how this method is used in practice outside of the test suite, but the additional parameter may impact users relying on the structure of that return value.

@danielfrankcom danielfrankcom changed the title postgres: Support direct SSL connections to Postgres 17+ servers feat(postgres): Support direct SSL connections to Postgres 17+ servers May 30, 2025
@danielfrankcom
Copy link
Author

Pushed an update which adds the new parameter to the doc.md file which I missed originally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PostgreSQL client should support direct SSL connections to Postgres 17+ servers
1 participant