Sécurisation de l'émission d'un certificat à l'aide de la validation de contrôle de domaine par chemins multiples

Cet article de blog fait partie de la Crypto Week 2019.

La confiance sur Internet repose sur l'infrastructure à clé publique (PKI). L'infrastructure à clé publique permet aux serveurs de servir de manière sécurisée des sites Web en émettant des certificats numériques, constituant ainsi la base d'une communication cryptée et authentique.

Les certificats rendent le cryptage HTTPS possible en utilisant la clé publique du certificat pour vérifier l'identité du serveur. HTTPS est particulièrement important pour les sites Web qui transmettent des données sensibles, comme les identifiants bancaires ou les messages privés. Heureusement, les navigateurs modernes, tels que Google Chrome, signalent les sites Web non sécurisés à l'aide du protocole HTTPS en les signalant comme « non sécurisés », ce qui permet aux utilisateurs d'être plus conscients de la sécurité des sites Web visités.

Cet article de blog présente un nouvel outil gratuit que Cloudflare propose aux autorités de certification pour leur permettre de sécuriser davantage l'émission de certificats. Mais avant d’aller plus loin, parlons de l’origine des certificats.

Les autorités de certification (AC) sont les établissement responsables de l'émission des certificats.

Lorsqu'elles émettent un certificat pour un domaine donné, elles utilisent la Validation de contrôle de domaine (DCV) pour vérifier que l'entité demandant un certificat pour le domaine est le propriétaire légitime du domaine. Avec DCV le propriétaire du domaine :

1. crée un dossier de ressource DNS pour un domaine ;

2. charge un document sur le serveur Web situé dans ce domaine ; OU

3. prouve la propriété du compte de messagerie administratif du domaine.

Le processus DCV empêche les pirates d'obtenir des paires de clés privées et de certificats pour des domaines qui ne leur appartiennent pas.

Il est essentiel d'empêcher les pirates d'acquérir cette paire : si un certificat mal émis et une paire de clés privées se retrouvent entre les mains d'un pirate, il pourrait se faire passer pour le domaine de la victime et utiliser le trafic HTTPS sensible. Cela détériore la confiance que nous accordons à Internet et compromet les données privées à une échelle potentiellement massive.

Par exemple, un pirate qui incite une AC à émettre un faux certificat pour gmail.com, pourrait alors établir un système de communication TLS en prétendant être Google, puis exfiltrer des cookies et des informations de connexion pour accéder au compte Gmail de la victime. Les risques d'émission de faux certificats sont clairement élevés.

Pour éviter de telles attaques, les autorités de certification ne délivrent un certificat qu'après avoir effectué la DCV. Un moyen de valider la propriété du domaine consiste à utiliser la validation HTTP en chargeant un fichier texte sur un point de terminaison HTTP spécifique sur le serveur Web à sécuriser.  Une autre méthode DCV consiste à utiliser la vérification par courrier électronique, en envoyant un e-mail avec un lien de code de validation au contact administratif du domaine.

Supposons qu'Alice achète le nom de domaine aliceswonderland.com et souhaite obtenir un certificat dédié à ce domaine. Alice choisit d'utiliser Let’s Encrypt comme autorité de certification. Tout d'abord, Alice doit générer sa propre clé privée et créer une demande de signature de certificat (CSR). Elle envoie la CSR à Let’s Encrypt, mais l’AC ne délivrera pas de certificat pour cette CSR et cette clé privée tant qu’elle ne saura pas que Alice est propriétaire de aliceswonderland.com. Alice peut ensuite choisir de prouver qu'elle est propriétaire de ce domaine via la validation HTTP.

Lorsque Let’s Encrypt exécute DCV sur HTTP, il demande à Alice de placer un fichier nommé de manière aléatoire dans le chemin /.well-known/acme-challenge pour son site Web. L'autorité de certification doit récupérer le fichier texte en envoyant une demande HTTP GET à http://aliceswonderland.com/.well-known/acme-challenge/ <nom_fichier_aléatoire>. Une valeur attendue doit être présente sur ce point de terminaison pour que DCV réussisse.

Pour la validation HTTP, Alice chargerait un fichier sur http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

où le corps contient :

curl http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

GET /.well-known/acme-challenge/YnV0dHNz
Host: aliceswonderland.com

HTTP/1.1 200 OK
Content-Type: application/octet-stream

YnV0dHNz.TEST_CLIENT_KEY

L'AC leur indique d'utiliser le jeton YnV0dHNz Base64. TEST_CLIENT_KEY dans une clé liée au compte que seuls le demandeur du certificat et l'autorité de certification connaissent. L'autorité de certification utilise cette combinaison de champs pour vérifier que le demandeur de certificat est réellement propriétaire du domaine. Ensuite, Alice peut obtenir son certificat pour son site Web !

Les utilisateurs peuvent également valider la propriété d'un domaine en ajoutant un dossier DNS TXT contenant une chaîne de vérification ou un jeton de l'autorité de certification aux dossiers de ressources de leur domaine. Par exemple, voici un domaine pour une entreprise qui se valide auprès de Google :

$ dig TXT aliceswonderland.com
aliceswonderland.com.	 28 IN TXT "google-site-verification=COanvvo4CIfihirYW6C0jGMUt2zogbE_lC6YBsfvV-U"

Ici, Alice choisit de créer un dossier de ressource TXT DNS avec une valeur de jeton spécifique. Une autorité de certification Google peut vérifier la présence de ce jeton pour approuver qu'Alice est réellement propriétaire de son site Web.

L'émission de certificats est requise pour que les serveurs puissent communiquer de manière sécurisée avec les clients. C’est pourquoi il est si important que le processus d'émission des certificats soit également sécurisé. Malheureusement, ce n'est pas toujours le cas.

Des chercheurs de l'Université de Princeton ont récemment découvert que les méthodes DCV courantes sont vulnérables aux attaques exécutées par des pirates au niveau du réseau. Si le Border Gateway Protocol (BGP) est le « service postal » d’Internet responsable de la transmission des données par les itinéraires les plus efficaces, alors, les Systèmes autonomes (AS) sont des succursales de bureaux de poste individuelles qui représentent un réseau Internet géré par une seule organisation. Parfois, des pirates de niveau réseau annoncent de fausses routes sur BGP pour détourner le trafic, en particulier si ce trafic contient quelque chose d'important, tel que le certificat d'un domaine.

Les autorités de certification Bamboozling avec BGP mettent en évidence cinq types d'attaques pouvant être orchestrées pendant le processus DCV visant à obtenir un certificat pour un domaine qui n’appartient pas au pirate. Après avoir mis en œuvre ces attaques, les auteurs ont pu (éthiquement) obtenir des cinq autorités de certification principales, des certificats pour des domaines qu'ils ne possédaient pas : Let’s Encrypt, GoDaddy, Comodo, Symantec et GlobalSign. Mais comment ont-ils fait ?

Le détournement BGP permet d’attaquer le processus DCV de deux manières principales :

1. Attaque de sous-préfixe

2. Attaque par préfixe spécifique de même degré d'égalité

Ces attaques créent une vulnérabilité lorsqu'un pirate envoie une demande de signature de certificat pour le domaine de la victime à une autorité de certification. Lorsque l'autorité de certification vérifie les ressources réseau à l'aide d'une requête HTTP GET (comme indiqué précédemment), le pirate utilise ensuite des attaques BGP pour détourner le trafic vers le domaine de la victime, de manière à ce que la demande de l'autorité de certification soit réacheminée vers le pirate et non vers le propriétaire du domaine. Pour comprendre comment ces attaques sont menées, nous devons d’abord faire un peu de calcul.

Chaque appareil sur Internet utilise une adresse IP (Protocole Internet) comme identifiant numérique. Les adresses IPv6 contiennent 128 bits et suivent une notation en barre oblique pour indiquer la taille du préfixe. Ainsi, dans l’adresse réseau 2001: DB8:1000::/48, « /48 » désigne le nombre de bits que contient le réseau. Cela signifie qu'il reste 80 bits contenant les adresses d'hôte, pour un total de 10 240 adresses d'hôte. Plus le numéro de préfixe est petit, plus le nombre d'adresses d'hôte restantes sur le réseau est grand. Sachant cela, passons aux attaques !

Attaque un : Attaque de sous-préfixe

Lorsque BGP annonce un itinéraire, le routeur préfère toujours suivre l'itinéraire le plus précis. Ainsi, si 2001:DB8::/32 et 2001:DB8:1000::/48 sont annoncés, le routeur utilisera ce dernier car il s’agit du préfixe plus spécifique. Cela pose un problème lorsqu'un pirate fait une annonce BGP à une adresse IP spécifique tout en utilisant l'adresse IP du domaine de la victime. Supposons que l’adresse IP de notre victime, leagueofentropy.com, soit 2001:DB8:1000::1 et annoncée comme 2001:DB8::/32. Si un pirate annonce le préfixe 2001:DB8:1000::/48, il capture le trafic de la victime en lançant une attaque de détournement de sous-préfixe.

Dans une attaque IPv4, telle que l'attaque d'avril 2018, il s'agissait d'annonces /24 et /23, la plus spécifique /24 étant annoncée par le pirate. Dans IPv6, cela pourrait être une annonce /48 et /47. Dans les deux cas, les blocs /24 et /48 sont les plus petits autorisés à être routés globalement. Dans le diagramme ci-dessous, /47 correspond au Texas et /48 est le plus spécifique d’Austin, au Texas. Les nouvelles routes (mais néfastes) ont remplacé les routes existantes pour des portions d'Internet. Le pirate a ensuite exécuté un serveur DNS néfaste sur les adresses IP normales avec des dossiers DNS orientant vers un nouveau serveur Web néfaste au lieu du serveur existant. Cela attirait le trafic destiné au domaine de la victime dans la zone où les itinéraires néfastes étaient en train de se propager. Cette attaque a réussi parce qu'un préfixe plus spécifique est toujours préféré par les routeurs destinataires.

Attaque deux : Attaque par préfixe spécifique de même degré d'égalité

Lors de la dernière attaque, le pirate a pu détourner le trafic en proposant une annonce plus précise. Mais que se passe-t-il si le préfixe de la victime est /48 et qu’une attaque par sous-préfixe n’est pas viable ? Dans ce cas, un pirate lancerait une attaque par préfixe spécifique de même degré d'égalité, où il annonce le même préfixe que la victime. Cela signifie que l’AS choisit l’itinéraire préféré entre les annonces de la victime et du pirate en fonction de propriétés telles que la longueur du trajet. Cette attaque n'intercepte toujours qu'une partie du trafic.

Il y existe des attaques plus avancées qui sont couvertes plus en profondeur dans le document. Ce sont des attaques fondamentalement similaires mais plus furtives.

Une fois qu’un pirate a réussi à obtenir un faux certificat pour un domaine qu’il ne possède pas, il peut alors lancer une attaque convaincante en se faisant passer pour le domaine de la victime, ce qui lui permet de déchiffrer et intercepter le trafic TLS de cette dernière. La possibilité de décrypter le trafic TLS permet au pirate de se positionner complètement au centre « Monster-in-the-Middle » (MITM) du trafic TLS crypté et de rediriger le trafic Internet destiné au domaine de la victime vers lui. Pour augmenter la furtivité de l’attaque, le pirate continuera d’acheminer le trafic à travers le domaine de la victime pour exécuter l’attaque de manière non détectée.

Un pirate peut également prendre le contrôle d'un domaine en usurpant le trafic DNS grâce à une adresse IP source appartenant à un serveur de noms DNS. Étant donné que tout le monde peut modifier les adresses IP sortantes de leurs paquets, un pirate peut simuler l'adresse IP de n’importer quel serveur de noms DNS impliqué dans la résolution du domaine de la victime et emprunter l'identité d'un serveur de noms lorsqu'il répond à une autorité de certification.

Cette attaque est plus sophistiquée qu’un simple envoi de spam à une autorité de certification avec des réponses DNS falsifiées. Étant donné que chaque requête DNS possède ses propres identifiants de requête aléatoires et son port d’origine, une fausse réponse DNS doit correspondre aux identifiants de la requête DNS pour convaincre. Étant donné que ces identifiants de requête sont aléatoires, il est extrêmement difficile d'effectuer une réponse usurpée avec les identifiants corrects.

Les pirates peuvent fragmenter les paquets de User Datagram Protocol (UDP) DNS de sorte que les informations d'identification de réponse DNS (telles que l'identifiant de requête DNS aléatoire) soient fournies dans un paquet, tandis que la section de réponse réelle suit dans un autre paquet. De cette façon, le pirate falsifie la réponse DNS à une requête DNS légitime.

Supposons qu'un pirate veuille obtenir un faux certificat pour victim.com en forçant la fragmentation de paquets et en usurpant la validation DNS. Le pirate envoie à un serveur de noms DNS pour victim.com un paquet « fragmentation nécessaire » ICMP avec une petite unité de transmission maximale ou une taille maximale d’octets. Cela oblige le serveur de noms à commencer à fragmenter les réponses DNS. Lorsque l'autorité de certification envoie une requête DNS à un serveur de noms pour victim.com demandant des dossiers TXT de victim.com, le serveur de noms fragmente la réponse en deux paquets décrits ci-dessus : le premier contient l'ID de la requête et le port source, que le pirate ne peut pas usurper, et le second contient la section de réponse que le pirate peut usurper. Le pirate peut continuellement envoyer une réponse falsifiée à l’AC tout au long du processus de validation DNS, dans l’espoir de la faire passer avant que l’AC ne reçoive la réponse réelle du serveur de noms.

Ce faisant, la section de réponse d'une réponse DNS (la partie importante !) peut être falsifiée et un pirate peut tromper une autorité de certification en l’emmenant à lui délivrer un certificat de manière incorrecte.

À première vue, on pourrait penser qu'un registre de transparence de certificat peut révéler un certificat mal émis et permettre à une autorité de certification de le révoquer rapidement. Toutefois, les registres CT peuvent prendre jusqu'à 24 heures pour inclure les nouveaux certificats émis, et la révocation des certificats peut être suivie de manière incohérente par différents navigateurs. Nous avons besoin d'une solution qui permette aux autorités de certification d'empêcher de manière proactive ces attaques et de ne pas y remédier de manière rétroactive.

Nous sommes ravis d’annoncer que Cloudflare fournit aux autorités de certification une API gratuite permettant de tirer parti de notre réseau mondial, afin d’effectuer la DCV à partir de plusieurs points de vue à travers le monde. Cette API renforce le processus DCV contre le détournement BGP et les attaques par usurpation de DNS.

Étant donné que Cloudflare exploite plus de 175 centres de données à travers le monde, nous sommes dans une position unique pour effectuer la DCV à partir de plusieurs points de vue. Chaque centre de données a un chemin unique vers les serveurs de noms DNS ou les points de terminaison HTTP, ce qui signifie qu'un détournement réussi d'une route BGP ne peut affecter qu'un sous-ensemble de requête DCV, ce qui entrave encore plus les détournements BGP. Et puisque nous utilisons RPKI, nous signons et vérifions les itinéraires BGP.

Ce vérificateur DCV protège en outre les autorités de certification contre les attaques par détournement et usurpation de DNS. La randomisation IP de la source de requête DNS est une fonctionnalité supplémentaire que nous avons intégrée au service et qui contribue à la protection contre les attaques par détournement. En rendant l'adresse IP source imprévisible pour le pirate, il devient plus difficile d'usurper le deuxième fragment de la réponse DNS de l'agent de validation DCV.

En comparant plusieurs résultats DCV collectés sur plusieurs chemins, notre DCV API rend pratiquement impossible pour un pirate de tromper une autorité de certification en la faisant croire qu’il possède un domaine alors que ce n’est pas le cas. Les autorités de certification peuvent utiliser notre outil pour s'assurer qu'ils ne délivrent des certificats qu'aux vrais propriétaires de domaine.

Notre vérificateur multi chemin DCV comprend deux services :

1. Les agents DCV chargés d'exécuter le DCV à partir d'un centre de données spécifique, et

2. un orchestrateur DCV qui traite les requêtes DCV multi chemin provenant des autorités de certification et les distribue à un sous-ensemble d'agents DCV.

Lorsqu'une autorité de certification veut s'assurer qu’une DCV s'est produite sans être interceptée, elle peut envoyer une demande à notre API précisant le type de DCV à exécuter et ses paramètres.

L'orchestrateur DCV transmet ensuite chaque demande à un sous-ensemble aléatoire de plus de 20 agents DCV situés dans différents centres de données. Chaque agent DCV exécute la requête DCV et transmet le résultat à l'orchestrateur DCV, qui regroupe ce que chaque agent a observé et le renvoie à l'autorité de certification.

Cette approche peut également être généralisée pour effectuer des requêtes multi chemin sur des dossiers DNS, comme le Certificate Authority Authorization (CAA). Les dossiers CAA autorisent les autorités de certification à émettre des certificats pour un domaine. Par conséquent, les usurper pour inciter les autorités de certification non reconnues à émettre des certificats est un autre vecteur d'attaque que l'observation par trajets multiples empêche.

Pendant que nous développions notre vérificateur de trajets multiples, nous étions en contact avec le groupe de recherche de Princeton qui a introduit la preuve de concept (PoC) de l'émission erronée de certificats via des détournements de session BGP. Prateek Mittal, coauteur de Bamboozling Certificate Authorities with BGP paper (autorités de certification Bamboozling avec le document BGP), a écrit :

« Notre analyse montre que la validation de domaine à partir de plusieurs points de vue atténue considérablement l'impact des attaques BGP localisées. Nous recommandons à toutes les autorités de certification d’adopter cette approche pour renforcer la sécurité Web. Une caractéristique particulièrement attrayante de la mise en œuvre de cette défense par Cloudflare est que Cloudflare a accès à un grand nombre de points de vue sur Internet, ce qui améliore considérablement la robustesse de la validation du contrôle de domaine. ».

Notre vérificateur DCV adhère à notre conviction que la confiance sur Internet doit être distribuée et vérifiée par le biais d'analyses de tiers (telles que celle fournie par Cloudflare) pour assurer la cohérence et la sécurité. Cet outil s’ajoute à notre moniteur de transparence de certificat préexistant en tant qu’ensemble des services que les autorités de certification sont invitées à utiliser pour améliorer l’expérience en matière d’émission de certificats.

La construction de notre vérificateur DCV à trajets multiples nous a également permis de « dogfood » plusieurs produits Cloudflare.

En tant que simple récupérateur et agrégateur, l'orchestrateur de DCV était un candidat idéal pour Cloudflare Workers. Nous avons implémenté l'orchestrateur dans TypeScript en utilisant ce message comme guide et avons créé un service orchestrateur dactylographié et fiable, facile à déployer et à améliorer. Heureusement, nous n’avons pas besoin d’entretenir notre propre serveur dcv-orchestrator !

Nous utilisons Argo Tunnel pour permettre à Cloudflare Workers de contacter les agents DCV. Argo Tunnel nous permet d’exposer facilement et en toute sécurité nos agents DCV dans Workers. Étant donné que Cloudflare compte environ 175 centres de données exécutant des agents DCV, nous exposons de nombreux services via Argo Tunnel et nous avons eu la possibilité de tester Argo Tunnel en tant que puissant utilisateur, avec une grande variété d'origines. Argo Tunnel a facilement géré cet afflux de nouvelles origines !

Si vous et/ou votre organisation voulez essayer notre vérificateur DCV, envoyez-nous un e-mail à dcv@cloudflare.com et dites-le-nous ! Nous aimerions en savoir plus sur la manière dont la requête et la validation par trajets multiples renforcent la sécurité de l'émission de vos certificats.

Alors qu’une nouvelle forme d’attaque par usurpation d’IP et de BGP menace de saper les principes fondamentaux du PKI, il est important que les propriétaires de sites Web préconisent la validation par trajets multiples lorsqu’ils reçoivent des certificats. Nous encourageons toutes les autorités de certification à utiliser la validation par trajets multiples, qu’il s’agisse de celle de Cloudflare ou de la leur. Jacob Hoffman-Andrews, responsable technique de Let’s Encrypt, a écrit :

« Le détournement BGP est l’un des grands défis que le PKI Web doit encore résoudre, et nous pensons que la validation par trajets multiples peut faire partie de la solution. Nous testons notre propre implémentation et nous encourageons les autres autorités de certification à poursuivre également la propagation par trajets multiples. ».

Espérons qu'à l'avenir, les propriétaires de sites Web examineront la prise en charge de la validation par trajets multiples lors de la sélection d'une autorité de certification.