Exercise 3: Man-in-the-Middle Against a Database Connection — Possible Solution
====================================================================

A man-in-the-middle (MITM) attack against a database connection would
look like this: an attacker positioned somewhere on the network path
between the application and the real database intercepts the
connection attempt. Instead of letting it reach the real database
server, the attacker's own machine answers in its place, presenting
ITS OWN TLS certificate to the application.

If the application is only checking that SOME certificate was
presented and that the channel is encrypted (the sslmode=require
situation from Exercise 2), it has no way to tell that this
certificate doesn't actually belong to the real database — it accepts
the connection, encrypts everything with the attacker's keys, and
proceeds normally, completely unaware anything is wrong. The attacker
can then read every query and response in plaintext (having decrypted
it on their end), and even relay it on to the real database to keep
the application working normally, making the attack invisible from the
application's side.

WHY CERTIFICATE VERIFICATION SPECIFICALLY IS WHAT PREVENTS THIS:
encryption alone only protects data from being read by a passive
eavesdropper who ISN'T actively intercepting the connection — it does
nothing to confirm WHO the encrypted channel was actually established
with. Certificate verification (verify-ca/verify-full) is the step
that checks whether the certificate presented was signed by a trusted
certificate authority and matches the expected server — exactly the
same identity check https1-5's chain-of-trust material describes for
HTTPS. Without that check, an attacker doesn't need to break the
encryption at all; they simply present their own valid-looking
certificate and get treated as the real server, which is precisely why
"encrypted" and "verified" are two separate properties, and why
skipping verification defeats the point of using TLS against this
specific attack.