Les certificats de courte durée réduisent le risque d'usurpation d'identité sur les sites web
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 Transport Layer Security (TLS)) pour empêcher l'usurpation d'identité de leur domaine et l'interception de leurs connexions HTTP over TLS (HTTPS) cryptées.
Contrairement au remplacement des serrures et des clés physiques, les clés cryptographiques désaffectées continuent souvent de 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 relie 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. Si elle est trop longue, 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 des 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 réel 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 la façon dont cela peut se produire :
- 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 tiers.
| Date Range | # Certs / day | # Fully Qualified Domain Names/day | #Second-Level Domains/day | |
|---|---|---|---|---|
| Key compromise | 2021-2023 | 493 | 787 | 347 |
| Domain owner change | 2013-2021 | 2,593 | 2,807 | 1,214 |
| Managed TLS change | 2022 | 9,495 | 18,833 | 7,722 |
Atténuations potentielles
La manière apparemment évidente d'atténuer les certificats périmés est de les invalider en les révoquant. Toutefois, cette solution 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 de 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, réduisant ainsi 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é en matière d'informations sur les noms, ce qui permet aux opérateurs de noms d'agir 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.
