Earlier I wrote “Key-Exchange Logic for Encrypting Interface Data in Front-End/Back-End Separated Projects (RSA, AES)”, explaining the encryption/decryption strategy when front and back ends exchange data. As my understanding and grasp of network programming grew, two months later I had to write another addendum to patch my previous article, because improper use still can’t achieve absolute security. The previous article didn’t mention the man-in-the-middle attack, so I’m adding it here.
How the Man-in-the-Middle Attack Arises
The previous article “Key-Exchange Logic for Encrypting Interface Data in Front-End/Back-End Separated Projects (RSA, AES)” described the key-exchange process, but is that process really absolutely secure? As my understanding and grasp of network programming grew, I still needed to patch my previous article and warn about a security hole — the man-in-the-middle attack. How does it arise? Imagine the following scenario:
Our naive client wants to send a request to the server big brother for the “Server public key.” But at that moment DNS might be hijacked, or the network route might be hijacked, and our client’s data packet is diverted to some evil demon. The evil demon receives the letter and writes back in the server’s tone. Our naive client receives the evil demon’s reply but doesn’t know the other party isn’t the server big brother, so it takes it at face value and exchanges keys with the evil demon, and sends the account and password. This lets the evil demon get the user’s account and password. Afterwards, the evil demon unpacks and decrypts the client’s letters, then disguises itself as the client and re-packages and forwards them to the server big brother. In this way, all communication between our naive client and the server big brother is decrypted and collected by the evil demon.
Solving the Trust Problem
Based on the scenario I staged, this is actually a trust problem. Why should our naive client trust the letter it received? Because there’s no identity proof, right? Then we have to bring up HTTPS. Using HTTPS not only encrypts traffic but also identifies the other party’s identity, because the SSL certificate has a Domain field, i.e. the domain name, which effectively prevents someone from impersonating the server big brother.
So, to transmit data securely, you need not only correct encryption logic but also HTTPS.
The DNS Hijacking Problem
With the SSL certificate the problem is basically solved, but how could a perfectionist like me leave the problem unfinished? Above I also raised the DNS hijacking problem. Facing DNS pollution and DNS hijacking, there are two suggestions.
- Enable DNSSec at the domain resolution side. Domain Name System Security Extensions (DNSSEC) is a series of DNS security authentication mechanisms provided by the IETF (see RFC 2535). It provides an extension for source authentication and data integrity, but doesn’t guarantee availability, encryption, or proof that a domain doesn’t exist.
Since most domestic public DNS services don’t support DNSSec yet, there’s a second suggestion.
- Use HTTPDNS to resolve domain names. Instead of the traditional DNS resolution, use an HTTP-protocol-based DNS service. When the client needs DNS resolution, it directly requests the resolution result for the domain over the HTTP protocol.
On HTTPS Packet Capturing
When I suggest using HTTPS, there will surely be some contrarian who retorts that HTTPS can also be captured. Yes, if you use a packet-capturing tool yourself, it can be captured — but the premise is that you must import the packet-capturing tool’s CA certificate into the client. If an ordinary user’s phone or computer doesn’t have this packet-capturing tool’s CA certificate, then the SSL certificate re-packaged by the packet-capturing tool is untrusted, and the client will refuse the connection. If the hardware device has already fallen, then talking about subsequent security — isn’t that just being unreasonable?
Summary
The core point is to use HTTPS and not trust third-party certificates lightly; always validate through the system CA certificate chain. This solves the trust problem. Together with my previous article, both the trust problem and the encryption problem are now covered.