Bug SSL d'Apple : une autre attaque de type "Man-in-the-Middle".

Le problème

Vous avez peut-être entendu parler de la découverte récente d'une grave faille dans l'implémentation de SSL par Apple. Apple n'a pas donné beaucoup de détails, mais des chercheurs en sécurité connaissant bien le problème ont déclaré que la faille peut ouvrir la possibilité d'une attaque de type "man-in-the-middle" (MITM). Cela signifie que les systèmes non corrigés sont susceptibles de divulguer des mots de passe, des numéros de carte de crédit ou d'autres informations sensibles sans que l'utilisateur ne se rende compte que sa connexion n'est pas sécurisée. À l'heure où nous écrivons ces lignes, un correctif est disponible pour iOS 7, mais pas pour les machines Mac OS X.

Les attaques de type "man-in-the-middle" sur SSL ne sont pas du tout nouvelles ; en fait, j'ai fait une présentation il y a neuf ans, lors de la conférence RSA 2005, sur une attaque de type "man-in-the-middle" basée sur des logiciels malveillants que l'un de nos clients avait découverte, sur notre analyse du fonctionnement de cette attaque et sur ce qui pouvait être fait pour l'empêcher.

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.

Pour comprendre comment cela fonctionne, voyons d'abord comment fonctionne une attaque de type "man-in-the-middle". La plupart du temps, SSL est utilisé et ne nécessite qu'un certificat sur le serveur, comme indiqué ci-dessous :

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:

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.

Protection des clés privées

Avec n'importe quelle mise en œuvre de certificat numérique, tout tourne autour des clés privées ; si notre homme au milieu du diagramme ci-dessus accède à la clé privée du client, il est de retour dans les affaires. Une protection diligente des clés privées devient donc primordiale ; des technologies telles que la génération de clés sur l'appareil (ODKG) peuvent aider, car elles limitent les endroits où les clés privées peuvent être capturées ou exposées. Chaque fois que les clés sont générées en dehors de l'appareil, ce qui arrive fréquemment dans les scénarios mobiles ou BYOD, elles sont susceptibles d'être compromises partout où elles sont créées, transmises, stockées ou archivées. C'est pourquoi CSS insiste tant sur l'activation de l'ODKG dans des scénarios où il est difficile de le faire, y compris pour les appareils iOS et Mac.