Defense best practices for a man-in-the-middle attack

Man-in-the-middle attack defense requires careful, layered security. Michael Cobb reviews the tactics enterprises should employ to stay secure.

If a company has its own certificate authority (CA) and only signs user certificates if they use a one-time password...

(OTP) with a short time before expiration, can it be assumed that there is little chance (if any at all) for a man-in-the-middle attack?

Ask the Expert

Perplexed about application security? Send your questions today! (All questions are anonymous)

For clarity, I will describe your scenario in a little more detail before looking at whether it mitigates the risk of a man-in-the-middle (MitM) attack. The company in question operates its own certificate authority, possibly using Microsoft Certificate Services. It issues certificates to its users who are required to present them as part of the authentication process when accessing network resources. To add a possession factor to the process, users are also required to enter a one-time password (OTP) generated by some form of dongle that expires after a short period of time.

Unfortunately, MitM attacks -- where attackers insert themselves between client and server to impersonate the client when talking to the server and vice versa -- can easily circumvent this security control. After all, the attacker can pass any login credentials -- including the OTP value -- onto the server in real time, defeating the protection the ever-changing token value has to offer. Using a public-private key technology will provide protection against a MitM attack in this particular scenario.

By using mutual client-server authentication -- where each party sends a certificate to the other -- both the server and the client can be sure with whom they're communicating. In this situation, the only way an attacker could pull off a true MitM attack -- a two-sided impersonation -- would be to plant a rogue certificate authority in both the client and the server so that they trust a root CA that the attacker controls. A client certificate would not protect a user against a one-sided impersonation where they connect to a fake server as the attacker can just ignore the client's certificate.

MitM attacks against SSL communications are really only possible if:

  • The server key has been stolen.
  • A fake server key has been issued by a compromised CA.
  • The client doesn't validate the certificate correctly against its list of trusted CAs.
  • The client has been attacked and a fake CA has been injected in its trusted root authorities store.

In the past few years, numerous CAs have been compromised, allowing attackers to impersonate some fairly high-profile websites. To avoid this sophisticated yet very dangerous type of attack, any enterprise that issues its own certificates has to ensure its CA infrastructure is kept completely secure and physical access is also tightly controlled.

Users must control access to their client certificates via a password or pin and be shown how to check that a server's certificate is correct. Any system or browser warnings about a certificate not being valid should certainly stop any user from proceeding. The main threat to client-side certificates is phishing to try and retrieve the certificate and private key from the end user. When this happens, an attacker can easily impersonate the client. If the organization requires its users to provide an OTP, that would mean the attacker would also have to steal the physical device that generates the OTP. This requires the attacker to gain physical proximity to the victim, making the attack even more complex.

Sadly, there is no such thing as guaranteed security. However, the layers of defense in this scenario would take some work to defeat, and as long as these security controls are maintained and users are well-trained in spotting possible attacks, the chances of a successful MitM attack are slim. Sending the one-time password via an out-of-band device different from the client connected to the server would be one additional way to make this an even more secure strategy.

This was last published in April 2014

Dig Deeper on Web Server Threats and Countermeasures