Le directeur général est allé négocier un important contrat dans un pays étranger [1]. Son officier de sécurité l’avait averti sur les risques d’interception par le gouvernement local et de ne jamais mentionner le montant de l’offre française par téléphone. Il a également fait attention à ne jamais mentionner d’informations sensibles ni dans sa chambre d’hôtel ni dans les locaux avant la réunion finale. Le seul moment où il a mentionné le montant avant la soumission officielle, était par e-mail à son directeur financier pour avoir son avis suite à un changement de dernière minute. Cet e-mail était transmis sur un canal chiffré, le VPN SSL de l’entreprise. Il avait pris soin de s’authentifier avec son token et de vérifier l’absence d’erreurs de certificats. Pourtant… pourtant le champion local avait, semble-t-il, eu vent du montant et, au dernier moment, baissé son offre… à peine cent mille euros en dessous de la sienne. Le contrat était perdu, des mois d’efforts qui se soldent par un échec.Comment ce concurrent a-t-il fait ? Une nouvelle vulnérabilité dans SSL ? Un Zero-Day sur le concentrateur VPN ? Ou avait-il déjà compromis le SI de l’entreprise [2] ? Rien de tout cela : dans ce cas le gouvernement locala simplement utilisé une vulnérabilité inhérente à la conception du modèle de confiance de distribution des certificats SSL, afin d'aider l'entreprise concurrente.Cette attaque est connue depuis des années et documentée de façon spécifique en 2010 par Christopher Soghoian et Sid Stamm [Gov Cert] et rend accessible ce type d'interception de communications chiffrées à de nombreux gouvernements.Dans un premier temps, nous exposerons le fonctionnement de l’attaque avec un exemple de mise en œuvre technique puis nous aborderons différentes contre-mesures.
