Encryption in Transit
Database Security
Chapter 6 · Encryption in Transit
Chapter 5 protected data sitting on disk. This chapter protects the other half of the data's lifecycle — while it's moving across the network between an application and its database. The underlying cryptography is identical to the HTTPS/TLS course (https1) already on this site; this chapter is that same TLS applied to a database's own wire protocol instead of HTTP.
Why an Unencrypted DB Connection Is a Real Risk
Chapter 4's private-network binding controls who can reach the database's port — it says nothing about whether the traffic crossing that network, once a legitimate connection is allowed, can be observed by something in between. Even inside a "private" network, traffic still crosses physical switches, routers, and — in a cloud environment — a shared hypervisor layer other tenants' workloads also run on. An unencrypted connection means the login credentials and every query and response, including sensitive data, travel across that path in plain, readable text.
TLS for Database Connections
The same TLS mechanics the HTTPS course covered in depth — the handshake (https1-6), certificates (https1-4), symmetric and asymmetric cryptography (https1-2/https1-3) — apply directly here, just carrying a database's own wire protocol instead of HTTP. Every major database engine supports requiring TLS for connections.
Certificate Verification: The Part That's Easy to Get Wrong
Enabling TLS on its own only guarantees the connection is encrypted — it does not guarantee the server on the other end is actually the real database server, unless the client also verifies the server's certificate. This is the exact same certificate-chain-of-trust concept the HTTPS course covered (https1-5), and getting it wrong in a database connection string is a genuinely common, well-documented pitfall.
PostgreSQL sslmode | Encrypts? | Verifies the Server's Certificate? |
|---|---|---|
| require | yes | no |
| verify-ca | yes | yes — cert signed by a trusted CA |
| verify-full | yes | yes — cert signed by a trusted CA and matches the hostname |
sslmode=require is the setting most tutorials reach for first, since it's the shortest path to "TLS is now on." But it only encrypts the connection against passive eavesdropping — it does not verify the server's certificate at all, which means an attacker able to intercept the connection (a man-in-the-middle) can present any certificate, even a self-signed or unrelated one, and the client will happily proceed with an "encrypted" connection to the attacker instead of the real database. Only verify-ca or, better, verify-full actually confirm the server's identity — the same distinction between "encrypted" and "encrypted and authenticated" that https1-3 drew for HTTPS generally.
Why This Matters Even on a "Private" Network
Chapter 4's network isolation and this chapter's encryption in transit are two independent layers, not substitutes for each other — the same defense-in-depth principle Chapter 3 established for least privilege. Network isolation reduces who can attempt a connection at all; encryption in transit protects the data within a connection that's already permitted, against anything positioned to observe that traffic — a compromised intermediate host, a misbehaving piece of shared cloud infrastructure, or an insider (Chapter 1) already present on the same network segment. Neither layer alone covers what the other one does.
https1 course covers every one of them in much greater depth — the handshake, certificate chains, cipher suites, symmetric versus asymmetric cryptography. Nothing about TLS changes fundamentally when it protects a database connection instead of a browser's HTTP request; only the specific configuration flags (sslmode, --ssl-mode, tls=true) differ from one engine to the next.
Hands-On Exercises
Explain why a database connection on a "private" network can still benefit from TLS, even though Chapter 4 already restricts who can reach the database's port at all.
📄 View solutionA team configures their PostgreSQL connection string with sslmode=require and considers the connection fully secure. Explain what protection this setting is still missing, and which setting would fix it.
Using what you already know from the HTTPS/TLS course, explain in your own words what a "man-in-the-middle" attack against a database connection would look like, and why certificate verification specifically (not just encryption) is what prevents it.
📄 View solutionChapter 6 Quick Reference
- In transit = data moving across a network, between an application and the database — distinct from Chapter 5's "at rest"
- Even a private network can be observed — shared cloud infrastructure, a compromised intermediate host, or an insider already on the network
- TLS for databases uses the exact same mechanics as the
https1course — handshake, certificates, symmetric/asymmetric crypto — applied to a different wire protocol - Encryption alone isn't enough —
sslmode=requireencrypts but does not verify the server's certificate, leaving the connection open to a man-in-the-middle verify-ca/verify-full(or the equivalent in other engines) actually confirm the server's identity, not just encrypt the channel- Network isolation (Ch.4) and encryption in transit (this chapter) are independent layers — neither replaces the other
- Next chapter: Auditing & Logging — query logging, audit trails for sensitive table access, detecting anomalous access patterns