Simply put, MITM is an attack in which a third party gains access to the communications between two other parties, without either of those parties realising it. The third party might read the contents of the communication, or in some cases also manipulate it. So, for example, if Gerald sends Leila a message, intending it to be private, and Max intercepts the message, reads it, and passes it on to Leila, that would be a MITM attack. If Gerald wants to transfer £100 to Leila’s bank account, and Max intercepts the transaction and replaces Leila’s account number with his own, that would also be a MITM attack (in this case, Max is putting himself ‘in the middle’ between Gerald and his bank).
Why should I care?
Partly because MITM attacks can undermine so much of our modern way of life. In a connected life, we depend on the reliability and security of every connection. It’s not just about your conversations, messages and emails, either. If you can’t trust the connections you make to websites and online services, you may be vulnerable to fraud or impersonation, and if your connected devices and objects can’t communicate securely and reliably, they may put you and your household at risk.
The examples in this blog post are based on encrypted traffic between humans, but MITM attacks can affect any communication exchange, including device-to-device communication and connected objects (IoT). MITM attacks undermine the confidentiality and integrity of communications, and in doing so, they may open data, devices, and objects to malicious exploitation.
Imagine the danger if a hacker were able to trigger the airbags in a connected car, or remotely unlock an electronic door lock. The fact that connected objects can now affect the physical world introduces new factors to the risk assessment, especially in cases where physical infrastructure (transport, energy, industry) is automated or remotely controlled. An MITM attack on the control protocols for these systems, where an attacker interposes themselves between the controller and the device, could have devastating effects.
Is this something new?
Not in principle: MITM attacks have existed for as long as we have had to rely on others to convey our messages for us. When people used to seal their letters shut with wax and a personal seal, that was to protect against MITM attacks. The sealing wax didn’t make it impossible for a third party to break the wax and open the letter: it was intended to make it easy to tell if they had done so, because they would have difficulty replacing the wax and forging the impression left by the sender’s personal seal. This kind of protection is referred to as “tamper evidence”, and we see it in consumer products, too, such as the foil seal under the cap of a bottle of pills, or the cellophane wrapping around a packet of cigarettes.
If someone not only wanted to know if their letter had been tampered with, but also wanted to keep the contents confidential, they generally had to write the letter in a code that only the recipient would be able to decipher.
In the digital context, we can see equivalents for all these cases. For instance, if you send unencrypted email, the contents are visible to every intermediary and network node through which the traffic passes. Unencrypted email is like sending a postcard: the postman, anyone at the sorting office, and anyone with access to the recipient’s doormat can, if they choose, read the contents. If you want only the recipient to be able to read the contents of an email, you have to encrypt the email in such a way that only they can decrypt it, and if you want to ensure that no-one can change the contents without the recipient knowing, you have to apply an integrity check, such as a digital signature, to the message.
So, for unencrypted traffic, a MITM “attack” consists of making sure you have access to the message flow between Gerald and Leila.
For encrypted traffic, that isn’t enough; you’ll probably be able to see that Gerald is writing to Leila, because that information needs to go in clear in order for the message to be routed correctly. But you won’t be able to see the contents: for that, you’d need access to the key used to encrypt the message. In the kind of encryption normally used to secure messages, the message is encrypted and decrypted using two copies of the same key, just like sending someone a message in a locked cash box. For that to work, obviously, Gerald and Leila somehow have to exchange a copy of the key. So, in this case, a MITM attack would start by intercepting that traffic, which would then give an attacker (Max) the means to unlock the message after Gerald sends it, read it, re-encrypt it, and send it on to Leila, who will be none the wiser.
Here, we have two “flavors” of MITM attack. The first is to intercept the message contents themselves; the second is to intercept the key used to protect the traffic. Of these, message interception might simply be a case of sitting between the two communicating parties and reading the traffic; intercepting the key is likely to require active impersonation of the communicating parties. This is why successful MITM attacks put you at risk of being deceived… because, to work, they have to fool you into thinking you are talking to your intended partner, even if you are not.
What can I do about it?
A successful MITM attack will give the users at each end no clue that it is happening – especially if it has been designed into the infrastructure itself. The security of this kind of system, as a whole, depends on the security of a great many elements, all of which have to function properly. Some of those elements are in the user’s hands, but others are owned and operated by third parties (such as browser manufacturers and certificate authorities).
As a user, it’s important to understand the available signs that tell you if the system is working as intended:
- Distinguishing a secure browser session from an insecure one
- Recognizing a valid digital signature
- Knowing how to react appropriately to a certificate warning
It’s also important to practice good security hygiene with your passwords and keys. Of course, well-designed systems will make this easy for you, but regrettably, not all systems are designed with that goal in mind.
Want to learn more?
In 2015 a group of experts in cryptography, IT security, computer science, security engineering, and public policy produced a paper in which they set out the implications of requiring access (by third parties) to encrypted communications. This is relevant because when governments request or require access to encrypted communications, they are essentially, in most instances, asking for a man-in-the-middle option to be built in to the products, services and/or infrastructure on which their citizens rely.