La révocation qui ne marche pas

Éditorial

CRL, OCSP, stapling, must-staple, CRLite : trente ans de tentatives pour qu'un certificat compromis cesse d'être cru. L'écosystème du web a fini par répondre en raccourcissant la vie des certificats, ce qui est un aveu d'échec autant qu'une solution.

Mis à jour le 25 septembre 2026~27 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Une promesse que personne ne tient

Un certificat est une affirmation signée : « cette clé publique appartient à ce nom, jusqu’à telle date ». Toute la PKI repose sur l’idée que cette affirmation peut être crue par quelqu’un qui ne connaît ni le titulaire, ni l’autorité, et qui n’a aucun moyen de les appeler. C’est sa grandeur : la confiance voyage avec le certificat, comme le passeport voyage avec le touriste, sans que personne ne téléphone à la préfecture.

C’est aussi, dès l’origine, sa malédiction. Une affirmation signée ne se retire pas. Une fois émise, elle circule, elle est copiée, mise en cache, présentée par qui la détient. Si la clé privée fuit le lendemain de l’émission, le certificat continue d’affirmer la même chose, avec la même signature, jusqu’à la date de fin, avec l’aplomb tranquille des gens qui n’ont pas lu le journal. Le certificat ne sait pas qu’il ment. Il faut donc un second canal, extérieur au certificat, qui dise : « celui-là, ne le croyez plus ».

Ce second canal s’appelle la révocation, et cet éditorial raconte son échec. Pas un échec spectaculaire, avec une date, un coupable et une commission d’enquête : un échec lent, structurel, patient, où chaque génération de mécanisme a résolu le défaut le plus visible de la précédente pour aller buter, un peu plus loin, contre le même mur. Au bout de trois décennies, l’écosystème du web a cessé d’essayer de faire marcher la révocation et a choisi une solution d’une simplicité désarmante : faire mourir les certificats assez jeunes pour qu’on n’ait plus besoin de les exécuter.

J’ai l’âge d’avoir vu passer chacune de ces solutions définitives, et de les avoir crues, chacune à son tour, avec la ferveur des convertis tardifs. Je voudrais montrer que la dernière n’est pas un détail d’implémentation mais un aveu. Et que cet aveu dit quelque chose d’important sur ce qu’une infrastructure de confiance peut promettre, et sur ce qu’elle ne pourra jamais promettre, quel que soit le nombre de comités qui s’y emploient.

La liste noire, ou le problème de la fraîcheur

La première réponse est la plus naturelle, et l’humanité l’avait trouvée bien avant l’informatique : on affiche la liste des indésirables à l’entrée. C’est la CRL, Certificate Revocation List, décrite dans le profil X.509 de l’IETF. Chaque certificat indique où trouver la liste ; la liste est signée par l’autorité et porte deux dates, celle de sa publication et celle avant laquelle la suivante doit paraître. Le client télécharge, vérifie la signature, cherche le numéro de série. Simple, hors ligne, vérifiable. Trop beau, évidemment.

Trois défauts apparaissent immédiatement, et aucun n’est corrigeable à l’intérieur du modèle.

La taille. Une liste noire ne maigrit jamais tant que ses pensionnaires ne sont pas expirés. Pour une autorité qui émet massivement, elle atteint une taille qui rend son téléchargement coûteux à chaque connexion, et franchement comique sur un réseau mobile. Le jour d’une révocation massive (une vulnérabilité qui impose de remplacer des clés partout, comme Heartbleed en 2014), la liste enfle d’un coup, précisément au moment où tout le monde en a besoin. C’est le principe de l’ascenseur qui tombe en panne le jour de l’incendie.

La fraîcheur. Une CRL est une photographie, et les photographies ont ceci de fâcheux qu’elles vieillissent dès qu’on les développe. Entre deux publications, un certificat révoqué reste absent de la liste en circulation. Raccourcir l’intervalle augmente la charge ; l’allonger augmente la fenêtre. Il n’y a pas de bon réglage, seulement un arbitrage entre deux coûts, ce qui est la définition même de l’ingénierie et la raison pour laquelle on s’y ennuie rarement.

La disponibilité. C’est le défaut central, et on le retrouvera à chaque étape de ce chemin de croix. Si le client ne parvient pas à télécharger la liste (serveur en panne, réseau filtré, portail captif d’hôtel, simple lenteur), que doit-il faire ? Refuser la connexion, c’est rendre chaque site dépendant du serveur de listes de son autorité. Accepter, c’est admettre que la vérification n’a lieu que lorsqu’elle ne coûte rien, ce qui est aussi la politique de la plupart des gens en matière de vertu.

Les CRL incrémentales et les CRL partitionnées ont atténué la taille. Elles n’ont rien changé aux deux autres défauts. Pendant longtemps, sur le web grand public, les navigateurs ont traité les CRL comme une option, consultée ici, ignorée là, ce qui revient à dire que la liste noire existait surtout pour les auditeurs, qui sont des gens qu’il faut bien occuper.

OCSP, ou la question posée en direct

La deuxième génération inverse la logique. Au lieu de télécharger tout l’annuaire des proscrits, le client pose la question pour un seul certificat : « le numéro de série tel, émis par telle autorité, est-il toujours valide ? ». Un serveur de l’autorité, le répondeur OCSP (Online Certificate Status Protocol), renvoie une réponse signée, courte, avec sa propre durée de validité.

Sur le papier, les trois défauts de la CRL disparaissent. La réponse est minuscule. Elle peut être fraîche (en pratique, les répondeurs pré-calculent des réponses valables plusieurs heures ou plusieurs jours, ce qui reconstitue une fenêtre, mais ne gâchons pas l’enthousiasme). Et la charge est répartie : chacun ne demande que ce qui le concerne.

En pratique, OCSP a ajouté deux problèmes sans résoudre le troisième, ce qui, pour une deuxième génération, constitue une performance.

La latence. Chaque connexion vers un site inconnu exige désormais une requête supplémentaire, vers un serveur tiers, avant que la page ne s’affiche. Pour un navigateur dont la vitesse est un argument de vente, ajouter un aller-retour bloquant à chaque visite est un sacrifice que personne ne consent longtemps. On veut bien être en sécurité, mais pas au prix de trois cents millisecondes.

La vie privée. Le répondeur voit passer, pour chaque client, la liste des sites visités, avec l’heure. Ce n’est pas une fuite marginale : c’est un journal de navigation, tenu par un tiers que l’utilisateur n’a pas choisi, et transmis le plus souvent en clair, puisqu’on ne peut pas protéger par TLS la vérification d’un certificat sans vérifier d’abord un autre certificat, et ainsi de suite jusqu’à la fin des temps. On a donc construit, au nom de la confiance, un dispositif qui informe un inconnu de toutes vos lectures. L’ironie n’a échappé à personne ; elle n’a simplement dérangé presque personne.

La disponibilité, toujours elle, fidèle au poste. Si le répondeur ne répond pas, le client retrouve le choix qu’il avait avec la CRL. Et l’industrie a donné la même réponse.

Le soft-fail, ou la ceinture qui cède au choc

La réponse s’appelle soft-fail : en l’absence de réponse, le navigateur considère le certificat comme valide et poursuit. C’est le seul comportement viable pour un logiciel utilisé par des centaines de millions de personnes sur des réseaux imprévisibles. Un navigateur qui échouerait fermé afficherait une erreur chaque fois qu’un répondeur éternue, et ses utilisateurs, qui n’ont pas lu les exigences de base, changeraient de navigateur.

Mais il faut mesurer ce que ce choix implique, parce que c’est le cœur de tout l’éditorial, et que le cœur, comme on sait, est l’organe qu’on examine en dernier.

Qui a besoin que la révocation fonctionne ? Pas le visiteur d’un site honnête : pour lui, la réponse est une formalité. La révocation n’a de valeur que dans un seul scénario : quelqu’un présente un certificat dont la clé a été volée. Or quelqu’un qui présente un certificat volé est, dans l’écrasante majorité des cas, déjà en position d’intercepter le trafic de sa victime : même réseau Wi-Fi, point d’accès qu’il contrôle, routeur complaisant. Cette position lui permet de faire exactement une chose de plus : bloquer la requête de vérification.

Le raisonnement se referme sur lui-même avec une élégance de piège à loup. Le seul adversaire contre lequel la révocation protège est précisément celui qui peut la désactiver. En soft-fail, la vérification réussit tant que personne n’attaque, et elle cède silencieusement dès que quelqu’un attaque. C’est une ceinture de sécurité qui tient admirablement pendant les trajets ordinaires et se détache poliment au moment de l’accident. On a vu des dispositifs de sécurité plus inutiles ; on en a rarement vu d’aussi bien documentés.

Une révocation en soft-fail n’est pas une révocation affaiblie. C’est une révocation qui ne protège contre aucun attaquant actif. Elle garde une utilité contre l’attaquant passif ou maladroit, espèce qui existe mais qu’on ne rencontre guère dans les rapports d’incident. Elle garde surtout une utilité administrative : le certificat est officiellement révoqué, ce qui a des conséquences contractuelles et coche une case. La sécurité moderne est pleine de cases cochées par des mécanismes qui n’ont jamais rencontré leur ennemi.

C’est ce constat, formulé très tôt, qui a conduit certains navigateurs, dans les années 2010, à désactiver purement et simplement les vérifications OCSP en ligne par défaut pour les certificats ordinaires, au motif, difficile à contester, qu’on ne gagne rien à payer pour une protection qui s’évapore quand on en a besoin.

Le stapling, ou déplacer la corvée sur le serveur

Si le client ne peut pas interroger le répondeur de manière fiable, pourquoi ne pas faire poser la question par le serveur ? C’est l’agrafage OCSP, le stapling, défini comme extension de TLS. Le serveur interroge lui-même le répondeur à intervalles réguliers, obtient une réponse signée et datée, et l’agrafe à la poignée de main. Le client reçoit en même temps le certificat et un certificat de bonne vie et mœurs récent.

L’idée est élégante et règle deux problèmes sur trois. Plus de latence côté client. Plus de fuite de vie privée : le répondeur ne voit que le serveur, qui demande des nouvelles de lui-même. Et la charge du répondeur s’effondre, puisqu’il reçoit une requête par serveur et par période au lieu d’une par visiteur.

Pour savoir si un serveur agrafe, une commande en lecture seule suffit :

# Demande l'agrafe OCSP pendant la poignée de main et affiche la réponse reçue
# (remplacer exemple.org par le nom du serveur à examiner)
openssl s_client -connect exemple.org:443 -servername exemple.org -status \
  </dev/null 2>/dev/null | sed -n '/OCSP response/,/^---/p'

« OCSP response: no response sent » signifie que le serveur n’agrafe rien. Une réponse complète affiche l’état du certificat et ses dates.

Reste le troisième problème, qui n’a pas bougé d’un pouce. Que fait le client si le serveur n’agrafe pas ? Il ne peut pas refuser, puisque l’agrafe est optionnelle et que beaucoup de serveurs ne l’ont jamais activée. Il retombe donc sur le soft-fail. Et l’attaquant muni d’un certificat volé n’a aucune raison d’agrafer quoi que ce soit : il s’abstient, et le client ne distingue pas un serveur malveillant d’un serveur mal configuré, distinction qui, reconnaissons-le, est parfois subtile même pour un humain.

Le stapling améliore donc le sort des serveurs honnêtes, qui n’avaient pas de problème, et laisse intact celui de l’attaque, qui était le seul sujet. C’est une réforme de la prison qui améliore le confort des visiteurs.

Must-staple, ou l’engagement que personne ne voulait prendre

L’étape logique suivante consiste à rendre l’agrafe obligatoire, par un marqueur inscrit dans le certificat lui-même : c’est l’extension dite must-staple, qui dit au client « ne m’accepte qu’accompagné d’une réponse OCSP agrafée ». L’attaquant ne peut pas retirer le marqueur, signé par l’autorité, ni produire une agrafe valide pour un certificat révoqué. Pour la première fois, la révocation peut échouer fermée sans dépendre du répondeur au moment de la connexion, puisque c’est le serveur qui porte la charge de maintenir une agrafe fraîche.

Sur le papier, c’est la solution. Elle n’a presque jamais été adoptée, et les raisons sont d’une grande valeur pédagogique.

Elle transfère le risque de disponibilité sur le titulaire. Si le répondeur de l’autorité tombe assez longtemps pour que l’agrafe en cache expire, le site devient inaccessible. Le titulaire accepte donc que sa disponibilité dépende d’une infrastructure qu’il ne contrôle pas. C’est exactement l’arbitrage que les navigateurs avaient refusé pour leurs utilisateurs ; il est assez naturel que les exploitants le refusent pour leurs clients. On ne voit pas pourquoi l’abnégation serait mieux répartie en aval qu’en amont.

Les implémentations serveur étaient fragiles. Plusieurs serveurs web courants ont longtemps géré l’agrafe avec la désinvolture d’un concierge en août : récupération paresseuse à la première connexion, absence d’agrafe juste après un redémarrage, conservation soigneuse d’une réponse d’erreur. Un certificat must-staple sur un tel serveur produit des pannes intermittentes et indéchiffrables. Le gain de sécurité, lui, reste parfaitement invisible, ce qui est un mauvais rapport pour défendre un budget.

Le support client était incomplet. Tous les clients TLS ne respectaient pas le marqueur. Un mécanisme honoré par une partie des clients offre une protection partielle au prix d’un risque de panne total.

Le résultat est connu : must-staple est resté une coquetterie de spécialistes. Et quand une grande autorité de certification gratuite a annoncé la fin de son service OCSP, elle a cessé d’émettre des certificats portant ce marqueur, ce qui en a réglé le sort sur une part importante du web.

Must-staple était la seule variante d’OCSP qui résistait à l’attaquant actif, et c’est précisément celle-là qui n’a pas été déployée. Ce n’est pas un hasard, c’est une loi : la propriété qui la rendait sûre (échouer fermée) est la même que celle qui la rendait insupportable (échouer fermée). En sécurité, on appelle cela un compromis. Dans la vie, on appelle cela le choix entre la peste et la panne.

La révocation poussée par le navigateur

Faute de faire marcher la révocation en ligne, les navigateurs ont pris un autre chemin : ne plus demander, mais recevoir. Le navigateur télécharge périodiquement, par son propre canal de mise à jour, des données de révocation préparées par son éditeur, et les consulte localement. Plus de requête au moment critique, donc plus rien à bloquer.

Les listes sélectives

La première forme a consisté à pousser une liste restreinte : non pas toutes les révocations, mais une sélection jugée importante (autorités intermédiaires, incidents graves). C’est une révocation d’urgence plus qu’une révocation générale. Elle traite bien le cas rare et grave, comme l’affaire DigiNotar en 2011, où la réponse efficace a été le retrait de confiance par les navigateurs eux-mêmes, c’est-à-dire la peine capitale prononcée sans passer par le tribunal. Elle laisse de côté la masse des révocations ordinaires, qu’aucune liste exhaustive ne faisait tenir dans une mise à jour.

CRLite, ou la compression de l’ensemble

La seconde forme est la seule idée vraiment neuve de cette histoire, et il faut la saluer comme on salue un invité qui a apporté quelque chose. CRLite, proposé dans la recherche universitaire au milieu des années 2010 puis développé par l’équipe de Firefox, part d’une observation : le navigateur n’a pas besoin de la liste des certificats révoqués, il a besoin de répondre oui ou non pour un certificat donné. Et si l’on connaît l’ensemble de tous les certificats existants, on peut construire une structure compacte qui répond sans erreur pour chacun d’eux.

Cet ensemble est connu grâce à la transparence des certificats : les navigateurs exigent que les certificats publics soient inscrits dans des journaux publics, en ajout seul, consultables par tous. L’univers est donc énumérable. À partir de lui et des informations de révocation publiées par les autorités, on construit une cascade de filtres de Bloom, chacun corrigeant les faux positifs du précédent, qui répond exactement pour tous les certificats de l’univers et tient dans un volume raisonnable. Des mises à jour différentielles fréquentes entretiennent la fraîcheur.

C’est une belle construction, et elle a une propriété que rien d’autre n’avait : elle peut échouer fermée sans dépendre d’un tiers au moment de la connexion. L’attaquant sur le réseau peut bloquer tout ce qu’il veut ; la réponse est déjà dans la maison.

Ses limites, honnêtement : elle ne vaut que pour les certificats inscrits dans les journaux, donc pour le web public, pas pour la PKI de votre entreprise. Elle dépend de la qualité des informations publiées par les autorités, ce qui a justement poussé à rendre les CRL de nouveau obligatoires et complètes. Elle suppose un éditeur de navigateur capable d’agréger, compresser et distribuer, ce qui concentre une fonction de confiance de plus chez un acteur qui n’en manquait pas. Et sa fraîcheur dépend de la fréquence de mise à jour du client, ce qui réintroduit une fenêtre, plus courte mais réelle.

On remarquera avec une certaine tendresse que cette approche a ramené la vieille CRL au centre du jeu. Les autorités publient des listes complètes, non plus pour que chaque client les télécharge, mais pour qu’un agrégateur les compile. La liste noire n’a pas échoué parce qu’elle était une mauvaise idée, mais parce qu’elle était distribuée au mauvais endroit. Il arrive que les vieilles idées aient raison ; il leur faut simplement attendre que les jeunes aient essayé toutes les autres.

L’autre réponse : des certificats qui meurent jeunes

Parallèlement, une idée beaucoup plus brutale a pris le dessus. Si la révocation est lente, incomplète et contournable, il suffit de réduire la durée pendant laquelle elle serait nécessaire. Un certificat valable quelques jours n’a presque pas besoin d’être révoqué : si sa clé fuit, il mourra de sa belle mort avant que la révocation ait eu le temps de faire le tour du monde.

L’idée circulait dans la littérature bien avant que l’industrie s’en empare. Ce qui l’a rendue praticable, c’est l’automatisation de l’émission par le protocole ACME, et l’arrivée d’une autorité gratuite qui a imposé d’emblée des certificats de quatre-vingt-dix jours, à une époque où l’usage était de plusieurs années et où l’on renouvelait son certificat avec la même régularité que son passeport, c’est-à-dire la veille du départ. Une fois qu’une part importante du web renouvelait sans intervention humaine, raccourcir encore devenait une affaire de calendrier.

Le mouvement s’est accéléré en deux temps. La durée maximale des certificats publics a d’abord été ramenée à un peu plus d’un an. Puis le CA/Browser Forum a adopté une trajectoire de réduction par paliers, vers une durée maximale de l’ordre de quarante-sept jours à terme. Dans le même temps, les exigences de base ont rendu OCSP optionnel et les CRL obligatoires pour les autorités publiques, et plusieurs autorités ont annoncé l’arrêt de leurs répondeurs. Le calendrier et ses conséquences pour une petite infrastructure font l’objet de l’éditorial suivant.

Il faut lire ces décisions ensemble, comme on lit les testaments d’une même famille. Elles disent la même chose : l’écosystème a renoncé à rendre la révocation fiable au moment de la connexion, et il a choisi de rendre l’expiration assez rapide pour se passer de cette fiabilité. OCSP disparaît parce que sa charge et son indiscrétion ne sont plus justifiées par la protection qu’il n’offrait pas. La CRL revient parce qu’elle nourrit les mécanismes des navigateurs. Et la brièveté sert de filet pour tout le reste.

Pourquoi c’est un aveu

On peut présenter cela comme un progrès, et d’une certaine manière c’en est un. Mais soyons précis. La révocation promettait de retirer la confiance à la demande, immédiatement. Les certificats courts promettent de la retirer automatiquement, après un délai borné. La seconde promesse est plus facile à tenir, mais elle est plus faible. Entre la compromission et l’expiration, le certificat volé reste utilisable, et plus aucun mécanisme en ligne ne s’y oppose pour le client qui n’a pas de révocation poussée.

On a remplacé une promesse forte et mal tenue par une promesse faible et bien tenue. C’est souvent le bon choix en ingénierie, et presque toujours le bon choix en politique. Il faut seulement s’en souvenir, et cesser de parler de « révocation » dans les plaquettes comme si elle protégeait encore contre ce qu’elle était censée couvrir.

Pourquoi c’était perdu d’avance

Il y a une raison de fond à cette succession d’échecs, et elle dépasse les certificats.

Un système de confiance distribué ne peut pas offrir à la fois la vérification hors ligne et la révocation instantanée. C’est l’une ou l’autre. Si le client vérifie sans contacter personne, il ne peut pas apprendre, au moment de la vérification, que l’affirmation a été retirée. S’il doit l’apprendre immédiatement, il doit contacter quelqu’un, et la disponibilité de ce quelqu’un devient une condition de fonctionnement. Tous les mécanismes décrits ici sont des positions sur ce même axe : la CRL et CRLite parient sur une information préchargée, donc périssable ; OCSP parie sur la connexion, donc sur la disponibilité ; les certificats courts parient sur la date de fin, l’information la plus hors ligne qui soit, puisqu’elle était connue le jour de la naissance.

Ce n’est pas propre à X.509. Les jetons signés des API modernes (durée courte, révocation difficile, listes noires qu’on finit par interroger en ligne) rejouent exactement la même pièce, souvent avec les mêmes répliques et le même dénouement. Toute signature qui voyage seule pose la question de son retrait, et la question n’a pas de réponse qui ne coûte rien. Les serrures autonomes la posent aussi, version quincaillerie : une révocation ne les atteint qu’à la prochaine synchronisation, d’où les badges à validité courte revalidés chaque jour.

La deuxième raison tient aux incitations. La révocation bénéficie à quelqu’un qui n’en paie pas le coût. La latence, les pannes et la complexité sont supportées par le client et l’exploitant ; le bénéfice va à la victime éventuelle d’une attaque rare. Dans un marché où les navigateurs rivalisent de vitesse et les exploitants de disponibilité, un mécanisme qui dégrade les deux au profit d’une protection statistiquement discrète ne peut gagner qu’imposé. Les certificats courts, eux, l’ont été : par une autorité gratuite qui fixait ses conditions, puis par les programmes de confiance des navigateurs. La vertu, en informatique comme ailleurs, progresse surtout par décret.

La troisième raison est la plus inconfortable : la révocation a toujours été un geste administratif avant d’être un geste technique. La plupart des révocations n’ont rien à voir avec une clé volée : remplacement, changement d’avis, champ mal rempli, erreur d’émission. Le mécanisme a donc été dimensionné pour une foule de révocations sans enjeu et évalué sur des critères de conformité. Le cas de la clé volée entre les mains d’un attaquant actif, qui était sa seule raison d’être sécuritaire, s’est retrouvé noyé dans la paperasse, comme le seul dossier urgent d’une préfecture.

Le meilleur argument contraire

Il serait malhonnête, et un peu facile, de conclure que la révocation ne sert à rien. Voici l’argument le plus fort en sens inverse, et je le crois largement juste.

La révocation marche très bien là où l’on contrôle les deux bouts. Dans une PKI d’entreprise, pour l’authentification mutuelle entre services, pour les cartes à puce, pour des objets connectés, l’exploitant maîtrise l’autorité, le répondeur et les clients. Il peut configurer ces clients pour échouer fermés. Il peut rendre son répondeur aussi disponible que le reste de son infrastructure. Il n’a pas de problème de vie privée, puisque tout le monde appartient à la même maison. Dans ce cadre, les défauts décrits plus haut s’atténuent ou disparaissent, et la révocation retrouve la fonction qu’elle n’a jamais eue sur le web public. Les pages sur le mTLS et sur la liaison entre clé et identité décrivent ce contexte.

La révocation a aussi une valeur réelle en soft-fail, contre tout ce qui n’est pas un attaquant actif : un certificat émis par erreur, une clé publiée par mégarde dans un dépôt de code, un domaine qui change de mains. Révoquer arrête alors la plupart des usages, parce que la plupart des usages ne sont pas malveillants, ce qui est, au fond, la seule bonne nouvelle durable de notre métier. Et la révocation poussée a fini par couvrir l’attaquant actif pour une part croissante des navigateurs.

Enfin : les certificats courts ne remplacent pas la révocation, ils la complètent. Une autorité intermédiaire compromise, une erreur d’émission massive, un incident qui impose de retirer la confiance dans l’heure : aucune durée de vie, même de quelques jours, n’y répond.

Je retiens tout cela. Mais cet argument confirme la thèse au lieu de la réfuter. La révocation marche quand un seul acteur maîtrise la vérification : l’exploitant d’une PKI interne, ou l’éditeur d’un navigateur qui pousse ses propres données. Elle échoue précisément là où elle devait fonctionner sans cette maîtrise, entre un client quelconque et un serveur quelconque, par l’intermédiaire d’une autorité que ni l’un ni l’autre ne contrôle. La promesse initiale de la PKI (une confiance qui voyage sans intermédiaire central) n’a pas survécu. Elle a été remplacée par une confiance qui voyage, accompagnée d’un intermédiaire central qui dit quand cesser d’y croire. C’est moins romantique, mais ça fonctionne, ce qui est rarement le cas des choses romantiques.

Pour voir où un certificat annonce ses points de révocation, en lecture seule :

# Affiche les points de distribution de CRL et l'adresse du répondeur OCSP
# annoncés par un certificat (OpenSSL 1.1.1 ou plus récent)
openssl x509 -in certificat.pem -noout \
  -ext crlDistributionPoints,authorityInfoAccess

Un certificat public récent peut n’annoncer que la CRL, sans adresse OCSP : c’est cohérent avec l’évolution décrite plus haut, pas une anomalie.

Ce que je ne sais pas

Je ne sais pas mesurer l’efficacité réelle de la révocation poussée. Je n’ai aucun moyen fiable d’évaluer quelle part des clients en bénéficie, ni avec quel délai. Les navigateurs ne sont pas les seuls clients TLS : bibliothèques d’applications mobiles, outils en ligne de commande, clients embarqués, agents de mise à jour. Beaucoup n’ont aucune révocation poussée, et j’ignore ce qu’ils font en pratique quand OCSP disparaît. Je soupçonne qu’ils ne font rien, mais un soupçon de vieillard n’est pas une mesure.

Je ne sais pas comment se comportent les clients qui interrogeaient encore OCSP. Lorsqu’une autorité retire l’adresse OCSP de ses certificats, un client configuré pour l’exiger peut basculer sur la CRL, échouer ou ignorer. Les comportements par défaut que je connais sont hétérogènes, et je me méfie de toute généralisation, à commencer par les miennes.

Je ne sais pas si la concentration de la révocation chez les éditeurs de navigateurs est un problème durable. Elle fonctionne parce que ces éditeurs ont intérêt à la sécurité de leurs utilisateurs. Mais c’est un pouvoir de plus : celui de décider, pour une part considérable des internautes, quels certificats sont crus. Je n’ai pas d’avis tranché sur la manière dont ce pouvoir est contrôlé, et je me méfie de ceux qui en ont un.

Je ne sais pas où s’arrêtera la réduction des durées. Quarante-sept jours est un palier annoncé, pas une constante de la physique. Des certificats de quelques jours existent déjà. À partir d’une certaine brièveté, l’émission devient une révocation par défaut et la distinction s’efface. J’ignore ce que ce point d’arrivée coûtera en dépendance à la disponibilité des autorités, ce qui serait, ironie finale, le défaut d’OCSP déplacé au moment du renouvellement.

Ce qui reste

Trente ans de tentatives pour une conclusion qui tient en une phrase : on ne sait pas retirer une affirmation signée à un inconnu qui a le droit de ne pas vous écouter. Chaque mécanisme a été une manière différente de contourner cette impossibilité, et chacun a buté sur le même obstacle, la disponibilité, déguisé à chaque fois en autre chose.

Trois choses me semblent acquises. Que le soft-fail n’est pas un compromis mais une abdication face au seul adversaire qui compte, et qu’il faut le nommer ainsi plutôt que de cocher « révocation vérifiée » dans les grilles d’audit. Que la révocation fonctionne là où quelqu’un maîtrise les deux bouts, et nulle part ailleurs, ce qui en fait un outil d’infrastructure interne plutôt qu’une propriété du web. Et que les certificats courts sont une réponse raisonnable à un problème insoluble, à condition d’admettre qu’ils offrent une garantie plus faible que celle qu’ils remplacent.

Reste la conséquence pratique. Si la sécurité d’un certificat repose sur sa brièveté, elle repose sur la capacité de chaque exploitant à le renouveler sans faute, souvent, indéfiniment. On a déplacé le risque de la révocation vers l’automatisation. Pour une grande plateforme, c’est réglé. Pour une petite infrastructure, avec un serveur oublié derrière un pare-feu, un équipement qui n’accepte les certificats qu’à la main et une personne qui part en vacances, c’est un problème qui commence.

C’est le sujet de l’éditorial suivant.

🐝 Ce qui arrive si on s’en passe

Compter sur une révocation en échec ouvert, c’est inscrire « certificat révoqué » dans le rapport d’incident et considérer l’affaire close, alors que la clé volée reste acceptée par tout client qui n’obtient pas de réponse sur son statut. Pour un certificat émis pour plusieurs années, comme c’était l’usage avant l’automatisation, la fenêtre ne se compte plus en jours : l’attaquant capable de bloquer la vérification conserve l’identité usurpée jusqu’à l’expiration, avec la bénédiction administrative d’une révocation en bonne et due forme. Dans une infrastructure interne dont les clients n’ont pas été configurés pour échouer fermés, seule la date de fin met un terme à l’usurpation.

🦫 Explication de la marmotte 🍫

Un site sécurisé présente un certificat : un petit fichier signé par une autorité de confiance, qui affirme que telle clé appartient à tel nom jusqu’à une date donnée. Si la clé secrète du site est volée, le certificat reste valable jusqu’à cette date, car une signature ne peut pas être retirée. Il faut donc un autre moyen de dire « ne le croyez plus » : c’est la révocation. Première méthode : l’autorité publie une liste des certificats annulés. Cette liste s’alourdit, n’est mise à jour qu’à intervalles, et peut être impossible à télécharger. Deuxième méthode : le navigateur demande en direct à un serveur de l’autorité si un certificat est encore bon. Cela ralentit la visite et révèle à ce serveur les sites consultés. Dans les deux cas, si la réponse n’arrive pas, le navigateur accepte quand même le certificat. Or un attaquant qui utilise un certificat volé est souvent placé sur le réseau de sa victime et peut bloquer cette question : la vérification cède justement pendant l’attaque. Faire joindre la réponse par le site ne règle rien, car l’attaquant peut ne rien joindre, et l’option qui rendait cette réponse obligatoire provoquait trop de pannes. Les navigateurs téléchargent donc désormais, à l’avance, des données compressées sur les certificats annulés, et les certificats durent de moins en moins longtemps. La révocation fonctionne vraiment lorsqu’un même responsable contrôle l’autorité et les ordinateurs qui vérifient.

Pages voisines

La citent

La révocation qui ne marche pas

Elle cite

: les deux pages se citent l’une l’autre.

La révocation qui ne marche pas

Une promesse que personne ne tient

La liste noire, ou le problème de la fraîcheur

OCSP, ou la question posée en direct

Le soft-fail, ou la ceinture qui cède au choc

Le stapling, ou déplacer la corvée sur le serveur

Must-staple, ou l’engagement que personne ne voulait prendre

La révocation poussée par le navigateur

Les listes sélectives

CRLite, ou la compression de l’ensemble

L’autre réponse : des certificats qui meurent jeunes

Pourquoi c’est un aveu

Pourquoi c’était perdu d’avance

Le meilleur argument contraire

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines