Skip to main content

SEC.CFG.TLS_DISABLED — The server does not offer TLS at all

  • Category: security
  • Severity: high
  • Level: 0
  • Confidence: deterministic
  • Downtime class: none — the finding is about a server parameter, not about a statement
  • Stability: stable
  • Suites: audit
  • Applies to: PostgreSQL 18

Stronger than an unenforced transport, and the difference decides what to fix first​

SEC.CFG.REQUIRE_SECURE_TRANSPORT reports a MySQL server that offers encryption and does not insist on it. Most connections there are in fact encrypted, and the finding is about a missing guarantee.

ssl = off is the other thing entirely. The server cannot negotiate TLS, so every connection to it runs in the clear — including the one you check to reassure yourself.

And no client can make up for it. Insisting on TLS against such a server fails the connection rather than securing it.

Why high and not critical​

Plenty of correct deployments reach PostgreSQL over a unix socket, or over a private network the database shares with nothing else. For those the exposure is bounded by that network rather than by this parameter.

critical is reserved for findings that need nothing else to be true. This one needs somebody to be able to reach the wire — which is why the combination that is critical (TLS off and an authentication rule accepting an open address range) is tracked as its own escalation rather than folded in here.

What it looks like​

# postgresql.conf: the server cannot negotiate TLS at all.
ssl = off

What to do about it​

# Offer TLS. A configuration reload picks this up; no restart.
ssl = on
ssl_cert_file = /etc/ssl/certs/server.crt
ssl_key_file = /etc/ssl/private/server.key

The parameter has context sighup: SELECT pg_reload_conf(); is enough, and there is no downtime to plan.

The case this cannot see​

A managed provider that terminates TLS at a proxy. The server parameter reads off while no connection reaches it in the clear. The finding says the server does not offer it, and leaves the deployment to you.

Whether a pooler sits in the path is established and reported beside the finding; what that proxy does with TLS is not. The finding stands either way, and on purpose — a pooler may pass TLS through untouched, so a detected proxy is not evidence that the server's own off is harmless.