Database drivers expose TLS connection modes such as 'require', 'verify-ca' and 'verify-full'. What does each one actually check, and which of them stop an attacker who can intercept the connection?

## The ladder Every mainstream driver exposes roughly the same five-step ladder, with different spellings: 1. **disable** -- no TLS at all. 2. **allow / prefer** -- opportunistic. Try one, fall back to the other. The critical property is that *plaintext is an acceptable outcome*: a network attacker who answers 'I don't support TLS' gets a cleartext session. This is a performance/compatibility setting, not a security setting, and it is the default in several drivers. 3. **require** -- the session must be encrypted, but the server's certificate is not validated. Confidentiality against a passive eavesdropper; zero protection against an active one, because the attacker simply presents a self-signed certificate and the client accepts it. 4. **verify-ca** -- the certificate chain must validate to a CA in the client's trust store or supplied bundle. Self-signed junk is now rejected. What is still missing is the binding between *this certificate* and *the host I asked for*: any certificate issued by a trusted CA passes. If that CA is a public one, that is catastrophic; if it is your internal CA, then any other server in the fleet -- or anyone who can get a certificate issued -- can impersonate the database. 5. **verify-full** -- chain validation plus a check that the hostname in the connection string matches the certificate's subject alternative name. This is the mode that gives you the actual guarantee 'I am talking to the database I named'. ## Why the distinction is asked about so often Because 'the connection is encrypted' is the answer people give, and it is the wrong answer. The whole value of a public-key handshake is authenticating the peer; encryption without authentication protects you from the weakest attacker (a passive listener) and not from the realistic one (someone who can redirect traffic via DNS, ARP, a rogue route, a compromised service discovery entry, or a hijacked cloud endpoint). A checklist item that says 'TLS enabled' and a connection string that says sslmode=require are a common audit gap. ## Operational realities of verify-full - **You must distribute a CA bundle.** Managed cloud databases publish a CA certificate; the app image or secret store must ship it, and it must be updated before the provider rotates its root. - **The hostname you dial must be on the certificate.** Connecting by IP address, through an internal CNAME, or through a service mesh name typically fails verify-full even though everything is configured correctly. The fix is to dial the certified name, not to downgrade the mode. - **Failover and replicas.** Multi-host connection strings and read replicas each present their own certificate; every name in the list must be certified. - **Proxies and poolers.** A pooler terminates TLS and presents its own certificate, so the client verifies the pooler, not the database. That hop must be secured separately. - **Expiry is now an availability risk.** With verify-full, an expired or mis-rotated server certificate takes the application down rather than degrading silently. That is the correct trade -- but it means certificate expiry needs monitoring like any other production dependency. ## Reasoning about the choice Ask what an attacker must do to defeat each mode. Defeating 'require' takes only the ability to answer the connection -- a DNS or routing trick. Defeating 'verify-ca' takes one certificate from the trusted CA. Defeating 'verify-full' takes a certificate issued for the exact hostname, meaning either a CA compromise or control of your issuance process. Only the last is a real bar. The corollary: a mode below verify-full should be a documented, time-boxed exception during a migration, not a steady state.