What is a man-in-the-middle attack and how can it intercept connections?
Published on 2026-10-20 by frfrand
Ataques de intermediario explicados: redes inseguras, TLS, certificados, advertencias del navegador y medidas de protección.
A man-in-the-middle attack —or intermediary attack— occurs when a third party manages to position themselves between two parties that believe they are communicating directly. That intermediary may attempt to observe, modify, or redirect traffic, depending on the connection's protections.
The idea is scary, but it doesn't mean that anyone sharing your Wi-Fi can automatically read all your encrypted messages.
The messenger example
Imagine you send a letter to a client. A person intercepts the envelope, opens it, changes a sentence, and then delivers it. If the recipient has no way to verify who sent the content or if it was modified, they might trust a fake letter.
In a digital connection, the problem is similar: one party believes they are talking to the authentic server, but someone tries to intervene along the way.
How could it happen?
There are different situations: malicious Wi-Fi networks, manipulated DNS configurations, compromised devices, or attempts to trick the user into accepting incorrect certificates.
Not all cases have the same scope. Being connected to a public network does not prove that an attacker exists, but it is advisable to take measures to protect sensitive connections.
Does HTTPS help?
Yes. HTTPS uses TLS to protect the confidentiality and integrity of communication and, when validated correctly, to authenticate the server you connect to.
That makes it extremely difficult for an intermediary to read or change content without the browser detecting it. But there are important conditions: you should not ignore certificate warnings, install unknown certificate authorities without understanding them, or trust fake pages just because they have a padlock.
Encryption protects the connection with the site you actually reached. If you voluntarily enter your credentials on a fraudulent domain with HTTPS, the padlock does not correct the deception.
And a VPN?
A VPN can protect traffic between your computer and the VPN exit point, depending on the protocol and configuration. It can be useful on untrusted networks, but it does not replace HTTPS nor eliminate malware or phishing risks.
It also involves trusting the provider and the destination team. Not all VPNs have the same level of privacy.
Signs worth investigating
A certificate warning that appears suddenly, a Wi-Fi network with a suspiciously similar name to the original, or unexpected redirects deserve attention.
But not all these symptoms prove a man-in-the-middle attack. An incorrect system date, an enterprise traffic inspection configuration, or a misconfigured server can also cause certificate failures.
The prudent thing is to stop sensitive operations and verify through a trusted channel what is happening.
How to protect an application?
Use TLS correctly, redirect HTTP to HTTPS where appropriate, maintain libraries and certificates, verify domain names, and protect administrative access.
For applications that handle money, accounts, or private information, it is also useful to review session, cookie, and security header handling. An encrypted connection does not replace a secure backend.
What about SSH?
SSH also uses cryptographic mechanisms to protect connections and authenticate the server. Verifying the host key helps detect suspicious changes and avoids blindly trusting any machine that responds.
Automatically accepting a new key without checking it when there is a warning can waste that protection.
How does it fit into ArduMaker?
If you manage VPSs and applications from ArduMaker, HTTPS for websites and verified SSH connections for administrative tasks help protect data traveling over external networks. Configuration and identity verification remain essential.
In summary: an intermediary seeks to intervene in a communication. Encrypted connections and correct destination verification are primary defenses, but security also depends on not providing information to fake sites.
Sources: TLS 1.3, RFC 8446 · HTTPS on MDN.