Lorsque les gens perdent leurs clés ou achètent une nouvelle maison, ils changent leurs serrures et utilisent une nouvelle clé. De même, lorsque les opérateurs de sites web perdent leurs clés cryptographiques ou achètent un nouveau nom de domaine, ils acquièrent un nouveau certificat web (un certificat TLS) pour empêcher l’usurpation d’identité de leur domaine et l’interception de leurs connexions chiffrées HTTP sur TLS (HTTPS).
Contrairement au remplacement des serrures et des clés physiques, les clés cryptographiques désaffectées continuent souvent à fonctionner. Cet article de blog explique pourquoi cela se produit et comment cela peut entraîner des problèmes de sécurité potentiels.
Certificats TLS périmés : Un problème de cache
Pour obtenir un certificat TLS, l’opérateur d’un site web doit prouver à une autorité de certification (AC) qu’il contrôle le serveur web de son domaine par le biais d’un échange défi-réponse.
Une fois le contrôle établi, l’autorité de certification émet un certificat TLS signé qui associe le nom de domaine du serveur web à sa clé cryptographique publique. Pour éviter une revérification constante du contrôle du serveur web, les certificats sont assortis d’une période de validité ou d’une durée de cache qui indique la durée de validité de la correspondance entre le domaine et la clé.
Si la période de validité du certificat est trop courte, les autorités de certification doivent supporter des coûts opérationnels supplémentaires pour revérifier le contrôle du serveur web et réémettre les certificats. S’il est trop long, un certificat peut devenir obsolète – ne plus représenter la correspondance réelle entre le domaine et la clé – et permettre à un adversaire de se faire passer pour le domaine de quelqu’un d’autre.
Découvrez comment les technologies habilitantes populaires telles que TLS1.3, DNSSEC et HTTP/3 sont en train de s’imposer dans le monde entier.
Usurpation de site web HTTPS
Examinons HTTPS, le principal protocole de sécurité du web, pour comprendre comment les certificats périmés peuvent poser problème. HTTPS utilise des certificats TLS pour authentifier les serveurs web et détecter les tentatives d’usurpation d’un site web par des tiers. En d’autres termes, seul l’opérateur actuel de example.com devrait être reconnu par un navigateur comme étant https://example.com.
Les certificats périmés peuvent rompre l’authentification du serveur HTTPS en permettant à un tiers d’usurper une connexion TLS pour le domaine de quelqu’un d’autre. Voici un exemple de ce qui peut se passer :
- Mallory acquiert le domaine foo.com
- Mallory acquiert un certificat pour foo.com valable un an.
- Mallory transfère/vend immédiatement le domaine à quelqu’un d’autre. Mallory peut maintenant se faire passer pour foo.com tant que son certificat est valide.
Mes collègues et moi-même de l’université d’État de l’Oregon, du Georgia Institute of Technology et de l’université de Stanford avons récemment étudié trois formes d’obsolescence des tiers (voir notre article).
Nous avons constaté qu’au cours des dix dernières années, plus de 4 millions de domaines (>1 000 par jour) avaient des certificats tiers périmés. Ces domaines comprennent des domaines populaires (61 dans le Top 1K d’Alexa) et des domaines impopulaires, et le nombre de certificats périmés a augmenté chaque année.
Bien que nous n’ayons pas pu déterminer si ces domaines vulnérables ont été activement exploités, l’ampleur de l’exposition met en évidence l’importance de l’atténuation des certificats TLS périmés de tierces parties.
| Plage de dates | # Nombre de certificats par jour | # Noms de domaine entièrement qualifiés/jour | #Nombre de domaines de deuxième niveau/jour | |
|---|---|---|---|---|
| Compromis clé | 2021-2023 | 493 | 787 | 347 |
| Changement de propriétaire de domaine | 2013-2021 | 2,593 | 2,807 | 1,214 |
| Changement de TLS géré | 2022 | 9,495 | 18,833 | 7,722 |
Atténuations potentielles
La manière apparemment évidente de limiter les certificats périmés est de les invalider en les révoquant. Toutefois, cette démarche se heurte à plusieurs obstacles, notamment :
- Tous les clients HTTPS (par exemple, les utilitaires de ligne de commande et les applications mobiles) ne prennent pas en charge la révocation.
- Certains supports de révocation ont une portée limitée (par exemple, Chrome/Chromium CRLSets) ou conduisent à des échecs progressifs, ce qui rend la révocation inutile contre un attaquant qui intercepte.
- La révocation est peu utilisée car elle est inefficace et/ou difficile à gérer.
La coordination avec les participants au système TLS pour surmonter ces difficultés pourrait réduire de manière significative la prévalence des certificats périmés. Mais une option plus accessible consiste à raccourcir les périodes de validité des certificats.
La communauté des autorités de certification et des navigateurs a évolué dans ce sens : la durée de vie maximale des certificats a été ramenée à 825 jours en 2017 et à 398 jours en 2020. Malgré cette amélioration de la sécurité, les certificats tiers périmés (et les domaines affectés) se sont multipliés depuis 2017.
La réduction des durées de vie maximales à 90 jours, que plusieurs grandes autorités de certification (par exemple, Let’s Encrypt) appliquent déjà d’elles-mêmes, pourrait éliminer jusqu’à 75 % de l’obsolescence des tiers.
Figure 2 – La réduction de la durée maximale de validité des certificats à 90 jours permettrait d’éliminer plus de 75 % des cas d’obsolescence des certificats délivrés par des tiers.
À plus long terme, la cause première de l’obsolescence des certificats est la conception actuelle de l’authentification des sites web basée sur les certificats, qui tente de relier des domaines, des serveurs web et des cycles de vie des certificats indépendants. Une solution plus fondamentale consiste à réduire la chaîne de dépendance du réseau entre les noms de domaine et leurs clés cryptographiques correspondantes, ce qui réduit les possibilités de rupture de dépendance involontaire ou malveillante.
Des propositions telles que l’authentification des entités nommées basée sur le DNS (DANE), le réseau centré sur le contenu (CCN) et le réseau de données nommées (NDN) alignent les clés cryptographiques sur la source faisant autorité pour les informations sur les noms, ce qui permet d’habiliter les opérateurs de noms et de minimiser les problèmes de mise en cache de l’authentification.
Pour en savoir plus, lisez notre article “Stale TLS Certificates“.
Zane Ma est professeur assistant à l’université d’État de l’Oregon. Il effectue des recherches sur la sécurité Internet, en se concentrant sur l’authentification de l’utilisateur, du client Web et du serveur.
Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l’Internet Society.