The countdown is on to Keyfactor Tech Days     | Secure your spot today!

  • Home
  • Blog
  • Apple’s SSL Bug: Another Man-in-the-Middle Attack

Apple’s SSL Bug: Another Man-in-the-Middle Attack

The Problem

You may have heard that a serious flaw in Apple’s implementation of SSL was recently discovered. Apple hasn’t offered much detail, but security researchers familiar with the issue have stated that the flaw can open up the possibility of a man-in-the-middle (MITM) attack. This means that unpatched systems are vulnerable to coughing up passwords, credit card numbers, or other sensitive information without the user being aware that their connection is insecure. At the time of this writing, a patch is available for iOS 7, but not for Mac OS X machines.

Man-in-the-middle attacks on SSL are not at all new; in fact, I gave a presentation nine years ago at the 2005 RSA Conference, about a malware-enabled man-in-the middle attack one of our customers had discovered, our analysis of how it worked, and what could be done to prevent it.

A Fix

From the limited amount of information that’s been provided so far, it sounds like there’s not much that iOS and Mac users can do about this until a patch is released and installed. But can organizations maintain some assurance that the users communicating with them are not MITM victims? In many cases, the answer may be “yes,” with the help of client-side SSL certificates.

To see how it works, let’s first look at how a man-in-the-middle attack works. Most of the time SSL is used, it involves only a certificate on the server, as shown below:

mim1

To be successful, the man in the middle must be able to convince the client that it’s talking directly to their intended endpoint. This is supposed to be impossible, if SSL is implemented properly (which appears to have been Apple’s problem), and appropriate trust anchors are maintained (which is sometimes easier said than done). If either of these aren’t upheld, man-in-the-middle attacks become possible.

But in mutual, or client-side SSL, the server requires that the client provide an authentication certificate as well. In this case, the server gains a level of assurance that it’s talking directly to the client:

mim2

Now the attackers’ task becomes at least twice as difficult, as they must convince both ends of the connection that they are communicating directly with each other, rather than just one.

Obviously, this specific problem with Apple iOS and Mac OS X will eventually be patched and go away. But it will almost certainly not be the last time we hear about a possible man-in-the-middle attack, and client-side certificates can help defend against MITM attacks the next time they come up as well. It’s worth noting, for example, that the server’s demand for a client certificate prevents the attack, even if the client’s machine is still unpatched and otherwise susceptible.

Private Key Protection

With any digital certificate implementation, it’s all about the private keys; if our man in the middle in the diagram above gets access to the client’s private key, he’s back in business. Diligent private key protection therefore becomes paramount; technologies such as On-Device Key Generation (ODKG) can help, as it limits the places where private keys can be captured or exposed. Any time keys are generated off-device, which frequently happens in mobile or BYOD scenarios, they are subject to compromise anywhere they are created, transmitted, stored, or archived. This is why CSS places so much emphasis on enabling ODKG in scenarios where it is otherwise difficult to achieve – including iOS and Mac devices.