PostgreSQL TLSv1 Protocol Version Auditor

The Incident (What Does the Error Mean?)

FATAL:  SSL error: tlsv1 alert protocol version
DETAIL:  SSL connection has been closed unexpectedly

This is an OpenSSL-level handshake abort. The server sent a protocol_version TLS alert (alert code 70) and killed the connection. This happens when:

1. The server's ssl_min_protocol_version is set to TLSv1.2 or higher (default in PostgreSQL 12+ and most managed services like RDS, Cloud SQL, Azure Database for PostgreSQL).
2. The client's TLS stack — libpq, a JDBC driver, psycopg2 linked against an old OpenSSL, or a connection pooler like PgBouncer — initiates a ClientHello advertising TLSv1.0 or TLSv1.1 as its maximum supported version.
3. Server rejects immediately. No data exchanged. Application crashes or connection pool exhausts.

Immediate consequence: Every connection attempt from that client fails. Zero fallback. Full outage for that service path.

The Attack Vector / Blast Radius

This isn't just a compatibility annoyance — running TLSv1.0/1.1 in production is an active security liability:

• POODLE (CVE-2014-3566) and BEAST attacks are practical against TLSv1.0. An attacker with network position (cloud VPC peering misconfiguration, shared-tenant environments) can decrypt session data.
• PCI-DSS 3.2.1 and HIPAA both explicitly require TLSv1.2 minimum. Running TLSv1 means you are out of compliance and liable in an audit.
• If the server is still accepting TLSv1 (the inverse problem — you disabled it on the client but not the server), any attacker who can intercept traffic can force a protocol downgrade by stripping the higher-version offer from the ClientHello.
• Blast radius in microservices: If a connection pooler (PgBouncer, pgpool-II) is the TLS terminator and it's the legacy client, every downstream service sharing that pool loses database access simultaneously. This is the most common production outage pattern for this error.

Prevention in CI/CD

1. Checkov — Scan IaC for weak TLS on managed PostgreSQL

# .checkov.yml
checks:
  - CKV_AWS_211   # RDS minimum TLS version
  - CKV_AZURE_28  # Azure DB for PostgreSQL SSL enforcement
  - CKV_GCP_6     # Cloud SQL require SSL

2. OPA/Conftest policy — Block Terraform plans with insecure TLS

package postgresql.tls

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_db_parameter_group"
  param := resource.change.after.parameter[_]
  param.name == "rds.force_ssl"
  param.value == "0"
  msg := "RDS PostgreSQL must enforce SSL (rds.force_ssl=1)"
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_sql_database_instance"
  resource.change.after.settings[_].ip_configuration[_].require_ssl == false
  msg := "Cloud SQL PostgreSQL must require SSL"
}

3. Pre-deploy smoke test in CI pipeline

#!/bin/bash
# ci/tls-check.sh — fail the pipeline if server accepts TLSv1
if openssl s_client -connect "$PG_HOST:5432" -starttls postgres -tls1 2>&1 | grep -q "Cipher"; then
  echo "FAIL: Server still accepts TLSv1. Deployment blocked."
  exit 1
fi
echo "PASS: TLSv1 correctly rejected."

Pin this in your GitHub Actions / GitLab CI as a required status check on the database infrastructure repo. A 30-second shell script has prevented more production TLS regressions than any enterprise scanner.