Lorsqu'une clé privée fuit, la révocation est censée vous protéger. Découvrez pourquoi les CRL et l'OCSP échouent en production.
Lorsqu'une clé privée TLS fuit ou est compromise, le certificat doit être invalidé avant sa date d'expiration. L'écosystème cryptographique s'appuie sur les listes de révocation de certificats (CRL) et le protocole d'état de certificat en ligne (OCSP) pour communiquer cette invalidation aux clients.
Cependant, dans les réseaux distribués, le maintien d'un état global en temps real est incroyablement difficile. C'est pourquoi les mécanismes de révocation connaissent souvent des défaillances invisibles.
Une CRL est simplement une grande liste, occasionnellement mise à jour, de numéros de série qu'une CA a révoqués. Avec la croissance d'Internet, le téléchargement de listes massives est devenu insoutenable. L'OCSP a été inventé pour résoudre ce problème, permettant aux clients d'interroger un répondeur de CA en temps réel pour vérifier le statut.
Le défaut fatal de l'OCSP est la latence et la fiabilité. Si un navigateur nécessite une vérification OCSP avant le chargement d'une page, et que le répondeur de la CA est hors ligne ou bloqué par un pare-feu, que se passe-t-il ?
Si le navigateur échoue durement (hard-fail), le site Web se déconnecte en raison d'une panne d'un tiers. Pour éviter de faire sauter Internet lors des pannes de CA, les navigateurs ont implémenté le 'soft-fail'. Si le répondeur OCSP expire, le navigateur suppose simplement que le certificat est valide.
Cela signifie qu'un attaquant réseau disposant d'un certificat compromis peut simplement bloquer les requêtes OCSP du client, forçant un soft-fail et réussissant à usurper l'identité du serveur.
La solution à cela est l'OCSP Stapling. Au lieu que le client demande à la CA, votre serveur récupère de manière asynchrone une réponse OCSP signée de la CA et l'en Agrafe ('staple') au handshake TLS.
Pour déboguer et vérifier si votre serveur agrafe correctement les réponses, utilisez OpenSSL :
openssl s_client -connect yourdomain.com:443 -status < /dev/null | grep -A 17 'OCSP response:'
S'il renvoie 'OCSP response: no response sent', votre agrafage est mal configuré, ce qui renvoie la charge de la validation et de la latence sur vos utilisateurs.
La gestion de l'agrafage et l'évaluation des chaînes de confiance nécessitent une validation externe continue. Heimdall Observer impose systématiquement une inspection approfondie du TLS à partir de plusieurs points de vue, garantissant que vos points de terminaison servent une cryptographie digne de confiance.
Rejoignez des milliers d'équipes qui comptent sur Heimdall pour maintenir leurs sites web et API en ligne 24h/24 et 7j/7. Commencez avec notre plan gratuit dès aujourd'hui.
Commencer la surveillance gratuitement
Ingénieur d'infrastructure axé sur le DNS, les réseaux et les couches invisibles qui déterminent si les applications sont accessibles.
