pgmoon never sends TLS SNI to PostgreSQL, making Kong unusable behind SNI-routing TCP proxies

[ArthurHoengen]

Summary

Kong cannot connect to a PostgreSQL database that sits behind a TCP proxy which routes by TLS SNI (Traefik, Neon, and similar). The bundled kong-pgmoon driver passes nil as the server_name argument to the OpenResty cosocket sslhandshake(), so Kong's ClientHello contains no SNI extension. The proxy cannot match a route, closes the connection, and Kong reports:

[error] 1256#0: *2 peer closed connection in SSL handshake, context: ngx.timer
Error: [PostgreSQL error] failed to retrieve PostgreSQL server_version_num: handshake failed

psql against the exact same endpoint, from the exact same pod, connects without any problem. No Kong configuration option changes this behaviour.

Environment

Kong version	3.6.0
Deployment	Kubernetes, official Kong Helm chart, role: control_plane
Database	PostgreSQL (CloudNativePG), TLS enabled, self-signed CA
Proxy in front of the DB	Traefik v3.7.4 with tls.passthrough: true and HostSNI(<hostname>)
pgmoon	kong-pgmoon == 1.16.2 (per kong-latest.rockspec)

Current behaviour

Kong configuration (this is the documented equivalent of sslmode=require + no certificate verification):

KONG_DATABASE=postgres
KONG_PG_HOST=postgres.example.com
KONG_PG_PORT=30432
KONG_PG_SSL=on
KONG_PG_SSL_REQUIRED=on
KONG_PG_SSL_VERIFY=off
KONG_PG_SSL_VERSION=any

Every migration and every control-plane start fails with handshake failed.

Expected behaviour

Kong connects, the same way psql "sslmode=require host=postgres.example.com port=30432 ..." does from the same network namespace.

Root cause

kong-pgmoon v1.16.2, pgmoon/init.lua, lines 928-950:

    send_ssl_message = function(self)
      local success, err = self.sock:send({
        self:encode_int(8),
        self:encode_int(80877103)      -- SSLRequest
      })
      if not (success) then
        return nil, err
      end
      local t
      t, err = self.sock:receive(1)    -- reads the 'S' / 'N' reply
      if not (t) then
        return nil, err
      end
      if t == MSG_TYPE_B.parameter_status then
        local _exp_0 = self.sock_type
        if "nginx" == _exp_0 then
          return self.sock:sslhandshake(false, nil, self.config.ssl_verify)   -- <<< line 944

Same code in the MoonScript source, pgmoon/init.moon:907:

  send_ssl_message: =>
    success, err = @sock\send {
      @encode_int 8,
      @encode_int 80877103
    }
    ...
    if t == MSG_TYPE_B.parameter_status
      switch @sock_type
        when "nginx"
          @sock\sslhandshake false, nil, @config.ssl_verify

The OpenResty cosocket signature is:

sock:sslhandshake(reused_session?, server_name?, ssl_verify?, send_status_req?)
                   |               |              |
                   false           nil            self.config.ssl_verify
                                   `-- SNI

The second argument is the SNI. It is hardcoded to nil — it does not come from self.config, and there is no option that feeds it. Kong always takes the "nginx" branch, so this path is unconditional.

It has never been implemented, in any version

Every tag of the Kong/pgmoon fork:

v1.7.0     578:  sslhandshake(false, nil, self.ssl_verify, nil, self.luasec_opts)
v1.8.0     580:  sslhandshake(false, nil, self.ssl_verify)
v1.9.0     584:  sslhandshake(false, nil, self.ssl_verify)
v1.10.0    587:  sslhandshake(false, nil, self.ssl_verify)
v1.11.0    587:  sslhandshake(false, nil, self.ssl_verify)
v1.12.0    587:  sslhandshake(false, nil, self.ssl_verify)
v1.16.1    944:  sslhandshake(false, nil, self.config.ssl_verify)
v1.16.2    944:  sslhandshake(false, nil, self.config.ssl_verify)

Current HEADs are unchanged:

• Kong/pgmoon, branch kong-dev, commit 6e8a52b (2026-04-20) — nil at lines 1039 and 1048
• leafo/pgmoon, master, commit 8667edd (2026-06-09) — nil at line 1113

git log --all -i --grep="sni" --grep="server_name" --grep="servername" returns zero commits in either repository.

To be clear, I don't think this is a regression — SNI for the PostgreSQL protocol simply predates nobody implementing it here. libpq itself only started sending SNI in PostgreSQL 14 (commit 5c55dc8b, which also added the sslsni opt-out). That is precisely why psql works and Kong does not.

Why this breaks specifically with Traefik

PostgreSQL does not do TLS-on-connect. The client opens in plaintext, sends an 8-byte SSLRequest, the server answers S, and only then does the TLS handshake start. Traefik implements this: it peeks for the PostgreSQL STARTTLS message and, if it matches, acknowledges it and signals the client to begin the TLS handshake, so it can read the SNI from the ClientHello and route (pkg/server/router/tcp/postgres.go).

The bytes pgmoon sends are exactly the ones Traefik looks for:

encode_int(8)        -> 00 00 00 08
encode_int(80877103) -> 04 d2 16 2f

So Traefik correctly identifies pgmoon as a PostgreSQL client and replies S (which pgmoon reads and compares against MSG_TYPE_B.parameter_status = "S"). Then it waits for the ClientHello to extract the SNI — and pgmoon sends none. No router matches, Traefik closes the connection, and OpenResty surfaces it as peer closed connection in SSL handshake.

Note that pg_ssl_verify=off cannot help here: this is a routing failure, and it happens before any certificate is ever presented.

Reproduction

The cleanest repro needs no Kong at all — openssl s_client reproduces both sides. Run both from inside the Kong pod, against a PostgreSQL endpoint behind a Traefik IngressRouteTCP using tls.passthrough: true and HostSNI(<hostname>):

# 1) WITH SNI — this is what psql/libpq >= 14 does. Works.
openssl s_client -connect postgres.example.com:30432 \
  -starttls postgres </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer

# subject=CN = my-postgres-rw
# issuer=OU = my-postgres-namespace, CN = my-postgres

# 2) WITHOUT SNI — this is what pgmoon does. Returns nothing.
openssl s_client -connect postgres.example.com:30432 \
  -starttls postgres -noservername </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer

# (empty — no certificate, handshake never completes)

A warning for anyone reproducing this: do not grep for Verify return code. The no-SNI run prints Verify return code: 0 (ok), which looks like success but is not — it is the default value of SSL_get_verify_result() when nothing was verified, because no certificate was ever received. It cost me a while. Check for the certificate itself.

The successful (SNI) handshake for reference:

SSL handshake has read 2621 bytes and written 851 bytes
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Verify return code: 19 (self-signed certificate in certificate chain)

19 is expected and harmless here — it's the CloudNativePG self-signed CA, and pg_ssl_verify=off ignores it.

Impact

Any Kong deployment whose PostgreSQL sits behind an SNI-routing TCP proxy is affected, and there is no configuration workaround — the fix has to be topological (a dedicated entrypoint with HostSNI(\*`)`, a direct LoadBalancer/Service, or bypassing the proxy). This is a well-known class of problem for PostgreSQL clients without SNI support:

• traefik/traefik#7507 — the request that led Traefik to implement PostgreSQL STARTTLS routing
• hashicorp/vault#20581 — same symptom: Vault fails behind an SNI proxy while psql works
• dbeaver/dbeaver#7758 — same setup, multiple PostgreSQL instances behind Traefik
• Neon's connection docs — Neon routes by SNI and therefore requires libpq >= 14

There is also an unanswered discussion with this exact error: #14675 (Kong 3.6.1, PostgreSQL 15, psql working over SSL). The only reply suggests adding the certificate to Kong's trusted CAs, which does not apply when pg_ssl_verify=off. I believe that report is this same issue.

Proposed fix

Kong already does exactly this for other TLS cosockets. The tcp-log plugin exposes conf.tls_sni and calls:

sock:sslhandshake(true, conf.tls_sni, false)

So the capability exists in Kong; it just never reached the database connection. Options, roughly in order of preference:

1. Mirror libpq. Default to sending self.config.host as server_name, with an opt-out — this is what libpq did in PG14 with sslsni (on by default). Lowest friction, matches what users already expect because psql works.
2. Add a config option, e.g. pg_ssl_sni (and pg_ro_ssl_sni for the read-only connection), plumbed through to the server_name argument.
3. At minimum, document that Kong does not send SNI on PostgreSQL connections, so people behind Traefik/Neon do not lose days on it.

The pgmoon change itself is one argument. Happy to open a PR against Kong/pgmoon if maintainers indicate which of the above they'd accept.

Questions

1. Is there a reason SNI was deliberately left out of the PostgreSQL connection that I'm missing?
2. Would you prefer this as an option (pg_ssl_sni) or as libpq-style default-on behaviour?
3. Is Kong/pgmoon the right place for the PR, or would you want it upstreamed to leafo/pgmoon first?

[jmrplens]

Reproduced, and your reading of the cause is right. I put a listener in front that answers the PostgreSQL SSLRequest preamble and then parses the TLS ClientHello, so the same hostname could be compared across clients on the same Docker network:

libpq 17 (psql)                        ClientHello 1565 bytes -> SNI = "pg.example.test"
pgmoon 1.16.2, stock Kong 3.9.3        ClientHello  299 bytes -> SNI = none

A plain TLS sniffer is not enough for this, incidentally, and it is the same reason ssl_preread cannot route PostgreSQL by SNI on its own: libpq sends its plaintext SSLRequest first and only starts TLS after the server answers S, so the ClientHello is not the first thing on the wire.

The line is pgmoon/init.lua, in the branch taken when sock_type is nginx, which is Kong's:

return self.sock:sslhandshake(false, nil, self.config.ssl_verify)

The second argument to the cosocket sslhandshake is server_name, and it is a literal nil. Kong itself passes one everywhere else it opens a TLS socket, sock:sslhandshake(false, conf.tls_sni, false) in the tcp-log plugin and conf.ldap_host in ldap-auth, so this is specific to the bundled pgmoon rather than a house style.

I also confirmed the fix is the obvious one. Mounting a pgmoon patched to self.sock:sslhandshake(false, self.config.host, self.config.ssl_verify) into the same Kong image, and changing nothing else, produced ClientHello 323 bytes -> SNI = "pg.example.test".

Upstream already has both halves open, worth subscribing to rather than re-filing: leafo/pgmoon#153 for the report and leafo/pgmoon#154 for a patch that adds an SNI test and fixes the hostname handling.

There is no Kong-side workaround through configuration. kong.conf exposes only pg_ssl and pg_ssl_verify for this connection, with nothing to set a server name, so until that lands the options are patching the bundled pgmoon/init.lua in your image or terminating TLS somewhere that does not route on SNI.

One detail to keep in mind when testing: SNI carries hostnames only, never IP literals. psql against 127.0.0.1 sent no SNI either, correctly, so pg_host has to be a name for any of this to matter.

[jmrplens]

Filed as #14989 so there is somewhere to track the pgmoon bump once leafo/pgmoon#154 lands, since this thread is in Help rather than the issue tracker. Credited to you there; the finding and the diagnosis were yours.