33c3 – Everything you always wanted to know about Certificate Transparency (Martin Schmiedecker)

Cet article est aussi disponible sur le CERT-Devoteam à l’adresse: CERT-Devoteam

En 2011, l’autorité de confiance Diginotar a été piratée et s’est faite voler son certificat principal. Suite à ce piratage, le certificat a permis de produire des certificats malicieux pour Google, Windows Update, Mozilla… ciblant tout d’abord l’Iran (99% des cibles) mais aussi le monde entier avec l’Europe, la Russie et les Etats-Unis pour des cibles isolées (activistes, expatrié, avocat). Le conférencier a mis en avant la nécessité de tirer des leçons de cet incident. En effet, le serveur ne disposait pas d’antivirus, le login était de la forme admin/admin, les logiciels non mis-à-jour, mais le problème principal réside dans l’absence d’information et de communications sur l’incident même après découverte. En effet une communication plus importante aurait permis de détecter plus vite la mise en place de ces attaques.

Cependant même après Diginotar, de nombreux incidents ont eu lieu. Dans les dernières années, on retiendra particulièrement :

  • le certificat adware Superfish installé par défaut sur les ordinateurs Lenovo (2015),
  • les certificats anti-datés produit par un sub-CA CNNIC afin d’éviter d’avoir à se conformer aux nouvelles réglementations sur l’utilisation de SHA dans la signature (2015),
  • la découverte de certificat de test valide par Symantec (2016),
  • Gogo, un fournisseur de service WiFi a produit de faux certificat afin d’analyser le trafic web dans les avions (2015).

De plus, l’association de Symantec (Authorité de Confiance) et Bluecoat (Solution de filtrage réseau) laisse craindre une interception des communications webà une échelle nationale comme cela a pu se produire lors du printemps arabe ou en Turquie. Enfin, de nombreux CA, près d’un tiers, n’ont jamais produit de certificat. On peut alors se poser des questions sur comment normaliser la situation.

Dans un monde idéal, les autorités de certification devraient publier systématiquement tous les certificats qu’elles ont signés. En effet, ce type de comportement permettrait de détecter rapidement les attaques. Google, du fait de sa position dominante, propose aujourd’hui une solution via la RFC 6962. Cette norme permet de proposer un archivage des certificats via l’utilisation d’un fichier à ajout uniquement. L’objectif de cette archive est de détecter les CA malveillants ou les faux certificats.

Cette RFC repose sur trois rôles:

  • Les logs collectors archivent les nouveaux certificats produits
  • Les monitors collectent toutes les informations et recherchent des anomalies (certificat soumis encore invisible, Sub-CA non indiqué)
  • Les auditors surveillent l’intégrité des fichiers de log et s’assure qu’aucun certificat actif ne soit supprimé

Tout le monde peut jouer ses rôles ce qui permet d’assurer une surveillance mutuelle.

Le mécanisme de fonctionnement repose sur un système d’ajout simple. Le CA envoie les informations au logs collector qui répond avec un Signed Certificate Timestamp (SCT) et une promesse d’ajout, le CA envoie ensuite le certificat signé avec le SCT au client. Le SCT contient un timestamp, un ID dans le fichier journal et une ou plusieurs méthodes pour vérifier la validité du SCT comme par exemple OCSP ou l’utilisation d’extensions TLS (Certificate Status Request). Il est important de retenir qu’un certificat donné peut avoir plusieurs SCT.

Du côté du logs collector le certificat est ajouté via un Merkel Hash Tree, c’est-à-dire un arbre binaire où chaque feuille est un hash des valeurs de ces deux enfants et où les feuilles sont les SCT. L’authentification est assurée ici par une signature de la tête de l’arbre, Signed Head Tree (SHT). Le temps d’insertion d’un certificat dans un arbre est de 24h au maximum, cependant les certificats ne sont pas ajoutés directement mais via l’utilisation de sous-arbres permettant d’éviter de remplir en permanence la base. La vérification peut alors se faire en recalculant l’intégralité de la base ou en utilisant un certificat témoin et en vérifiant l’intégralité de sa chaine.

Le conférencier a mis en avant la nécessité d’envisager le besoin d’effectuer une rotation des données. Cependant cette rotation doit être effectuée sous certaines conditions, en effet un arbre doit rester en vie jusqu’à ce que le dernier certificat expire.

Aujourd’hui Google gère 5 logs collector: 3 d’entre eux sont ouverts à tous, unest consacré à letsencrypt et un autorise tout le monde sauf letsencrypt. Ces services ont déjà permis d’identifier WoSign et Symantec. Google, par le biais de son navigateur, inclura bientôt l’obligation d’utiliser le Certificate Transparency à partir d’octobre 2017 et requerra en plus deux SCT pour les certificats à validation étendue (EV).

Il est possible dès aujourd’hui de participer en utilisant les logs collectors via des URLs particulières (/ct/v1/get-sth, /ct/v1/get-proof-by-hash …) ou via le moteur de recherche crt.sh .

Facebooktwitterlinkedin
Pierre d'Huy
Pierre d'Huy est un ingénieur spécialisé dans la sécurité des Systèmes d'Information. Il donne occasionnellement des conférences en école (ESE, ESGI Secure Day...) ou devant des publics non-techniques (Les matinées du droits Lamy, l'AFCDP). Amateur de cryptographie et de cartographie, il propose des articles sur de nombreux sujets qui le passionnent.

Leave a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *