Encryption protects a conversation only after it reaches the right endpoint
Encryption scrambles data so an observer who intercepts it cannot readily read it. But encryption by itself does not prove who is on the other end. If a device encrypts a message for an impostor, the impostor can decrypt it, make changes, and then start a separate encrypted connection to the intended server. Each stretch is protected; the whole exchange is not trustworthy.
This is a man-in-the-middle attack: an intermediary secretly places itself between two parties and relays messages while posing as each side to the other.
How a secure connection checks the server
When a browser connects to a secure website, the server presents a digital certificate. The certificate links the site’s name to a public key—the part of an encryption system that can be shared openly. The browser checks whether the certificate is valid for the requested name and whether it was issued through a chain of authorities the device trusts.
If those checks pass, the browser can use the public key to establish encryption with the server and confirm that it is communicating with the holder of the corresponding private key. If the checks fail, a warning may appear rather than silently treating the connection as secure.
Why the lock depends on both checks
The identity check and encryption solve different problems. Encryption helps keep intercepted traffic unreadable; authentication helps prevent an intermediary from substituting its own key and pretending to be the destination. Together, they make it harder to read or alter a conversation without detection.
That is why a secure-connection indicator is not merely a promise that data is scrambled. It reflects a check on whose key is being used—and, in turn, whose door the message is actually reaching.
