Three attackers hide behind one connect button, and encryption only stops one of them

A walkthrough published on dev.to takes apart the moment you type a host and a password into a database client, and argues the single click bundles three separate trust decisions: the network between you and the server, the server's claim about who it is, and the tool on your own machine that holds the password afterwards ^[2]. That matters because those three failures have three different defenders, and the common mistake, per the author, is turning on encryption and assuming it covered the other two ^[6]. The connection itself is a TCP conversation carrying two valuable things, your credentials and your query results ^[1]. Attacker one is passive: shared office wifi, a mirrored switch port, another tenant on the same cloud network, an ISP. They read what crosses the wire and do not alter it ^[3]. Attacker two is active, sitting on the path, answering for the database, relaying your conversation to the real server and reading everything in between; the author is blunt that a passive defense does nothing against them ^[4]. Attacker three never touches the network at all. They get your laptop, or a backup of it, or a folder that synced to the wrong cloud, and read the password your client saved ^[5]. Encryption stops the first, identity verification the second, and how the client stores secrets decides the third ^[6]. The mechanism is worth the thirty seconds the piece spends on it. Symmetric encryption uses one shared key to scramble and unscramble, which is fast, which is why the actual traffic is protected that way; the hard part is getting that key to both sides without an eavesdropper catching it in transit ^[9]. Asymmetric key pairs solve that, and two properties follow ^[10]. Each side can mix its own private key with the other's public key and independently arrive at the same shared secret, so a watcher who captured the entire exchange still cannot compute it ^[11]. And a message transformed with a private key can be checked by anyone holding the public key, which proves who sent it ^[12]. The first property is how a session key gets agreed in the open; the second is how identity gets proven ^[11][12]. TLS uses the first. The handshake agrees a fresh symmetric session key without ever sending it, then switches to that key, after which every byte is ciphertext and a full packet capture is noise to a passive observer ^[8]. Note the labelling: SSL and TLS are the same thing, SSL being the old name, so a form offering an SSL mode is offering TLS ^[7]. Nothing in that paragraph addresses attacker two, which is why the author's structure puts encryption at layer 1 and verifying who is on the other end at layer 2, then hiding the database from the internet at layer 3, swapping the stored password for a short-lived token at layer 4, protecting the secrets the client keeps on disk at layer 5, and what the client itself sends out at layer 6 ^[13]. Read that list against the three attackers and the split is clean: layers 1 through 3 are about the network path, 4 and 5 are about credentials at rest, and no single control spans both halves ^[16]. The title names TLS, SSH tunnels and IAM, which map to layers 1 and 2, layer 3, and layer 4 respectively, so the shopping list is really three shopping lists ^[17]. The author notes not every connection needs every layer and closes with three worked examples ^[15]. Disclosure worth carrying: the author works on FlexTable and uses it for the concrete option names ^[14]. Worth watching is whether the remaining layers hold up as well as the framing.