When a client application connects to a relational database over TLS, what exactly is protected, and which threats does that encryption not address?

## What is on the wire A database session is a long-lived TCP conversation carrying, in order: a startup message, an authentication exchange (password, hash, challenge-response or token), then every SQL statement, every bind parameter, and every row of every result set for the life of the connection. Anyone able to observe that path -- another workload on the same subnet, a compromised switch or hypervisor, a cloud operator, someone tapping a link between availability zones -- sees all of it in cleartext if TLS is off. That is why the database connection is a high-value target: it carries credentials *and* the crown-jewel data, and it is usually long-lived enough to be worth watching. ## The three guarantees **Confidentiality.** Once the session is encrypted, an observer sees only ciphertext plus traffic metadata (endpoints, timing, byte counts). Note the leftovers: the fact that a connection exists, its volume and its timing are still visible. **Integrity.** TLS records are authenticated, so an active attacker cannot flip a byte in your UPDATE, swap a row in a result set, or splice data in without the connection failing. Without TLS, a network attacker is not limited to reading -- they can rewrite the statement. **Server authentication.** The client checks the server's certificate against a trusted CA and against the hostname it dialled. This is what stops a man-in-the-middle from terminating your connection, harvesting the password, and proxying to the real database. Crucially this guarantee is *opt-in per client*: a mode that encrypts without validating the certificate gives confidentiality against a passive listener and nothing at all against an active one. **Client authentication (optional).** If the deployment requires a client certificate, the server also gets cryptographic proof of who is connecting, instead of (or in addition to) a shared secret. ## What is out of scope - **Data at rest.** Table files, indexes, redo logs, temp files and backups are unaffected. Someone who steals a disk image or a backup file is untouched by transit encryption. - **Authorization.** TLS says nothing about which tables or columns the connected role may read; grants and roles do that. "The connection is encrypted" is not an answer to "why can this service read the salaries table". - **Endpoint compromise.** Malware on the app host, a debug log that prints SQL and parameters, or a compromised database host all see plaintext regardless. - **Everything past the termination point.** If a pooler, sidecar proxy or load balancer terminates TLS, the segment from there to the database is a separate connection that must be encrypted separately, or you have just moved the plaintext hop. - **Application-layer leaks.** Query text in an APM trace or an error message is not covered. ## Consequences worth stating in an interview Because the credentials cross the wire before anything else, an unencrypted connection leaks the account that everything else depends on. Because replication and backup streams are also just client connections, they need the same treatment -- a hardened application path with a plaintext replica feed carries the same rows. And because "we are inside a private network" only shifts the attacker model to lateral movement, it is a reason to think about cost, not a reason to assume safety. ## How to verify Don't take the config file's word for it. Most engines expose, per live connection, whether it is encrypted; check that view (or the connection log line) in production and count the plaintext sessions. Configuration that *allows* TLS is not the same as clients that *use* it.