Résumé

  • Dans l'essai relaté par APNIC, un certificat Let's Encrypt révoqué figurait sur une CRL : Chrome et Safari ne l'ont pas rejeté, Firefox a reconnu la révocation.
  • Une observation ponctuelle ne décrit ni toutes les versions de ces navigateurs, ni tous les mécanismes de contrôle. Publication par la CA et application par le client sont deux événements distincts.
  • Les durées plus courtes, OCSP, l'agrafage et DANE déplacent des contraintes de temps, de disponibilité ou de confiance ; aucune de ces étiquettes ne prouve une protection immédiate.

Une autorité de certification peut affirmer qu'un certificat ne doit plus servir. Elle ne pilote pourtant pas chaque navigateur installé sur la planète. Le serveur garde sa copie du certificat, les points de distribution et les caches ont leur propre cadence, et le logiciel client décide quelles informations consulter, dans quel délai et avec quelle conséquence en cas d'échec. C'est dans cet espace entre les institutions que se situe la nouvelle de septembre.

Le compte rendu publié par APNIC le 21 septembre décrit l'expérience de son scientifique en chef Geoff Huston. Un certificat Let's Encrypt a été émis puis révoqué. Il apparaissait sur la liste de révocation. Dans les conditions observées, Chrome et Safari n'ont pas reconnu cette révocation, tandis que Firefox l'a reconnue. Le résumé ne fixe pas une matrice reproductible des versions, systèmes, paramètres, réseaux et heures de chaque connexion. Dire « ces navigateurs ne vérifient jamais » dépasserait donc la preuve.

La CRL est un document signé, doté d'une date de publication et d'une échéance pour sa prochaine mise à jour. La signature prouve l'origine de la liste, pas que chaque client l'a téléchargée après la modification. Une copie encore valable peut rester en cache. Dans son analyse technique d'avril, Huston décrit le coût d'une grande liste récupérée au moment de la négociation TLS. Le compte rendu d'APNIC donne l'exemple d'une liste hebdomadaire de 17 527 certificats révoqués et situe l'essai dans un cycle de sept jours. Ces chiffres illustrent le problème de distribution ; ils ne mesurent ni les victimes ni la durée d'une exposition précise.

OCSP évite de transporter toute la liste en demandant l'état d'un certificat. Il ajoute cependant un service à joindre, une latence possible et une fuite potentielle sur les sites visités. Sa réponse signée possède ses propres bornes temporelles : un « bon » état ancien n'est pas une déclaration éternelle. Avec l'agrafage, le serveur remet la réponse signée dans la négociation ; le client peut éviter une requête directe, mais le serveur qui présente encore un certificat révoqué n'est pas un distributeur désintéressé de la mauvaise nouvelle. Les choix d'échec ouvert ou fermé restent ceux du client.

Un point chronologique mérite d'être préservé. L'article d'avril rapporte un autre essai, portant sur OCSP, dans lequel Safari se comportait autrement. Il n'y a aucune raison de fusionner ces deux tableaux ou d'en tirer un classement permanent. Le protocole examiné, l'état des caches et la politique du client changent les conditions de la question. Pour septembre, la conclusion demeure limitée à l'expérience décrite par APNIC.

Raccourcir la durée d'un certificat borne le temps restant avant son expiration si le client la vérifie, mais ne retire pas une clé compromise à l'instant de l'incident. Cela accroît aussi l'importance d'un renouvellement et d'un déploiement fiables. Huston présente DNSSEC et DANE, avec les durées de cache DNS, comme une autre architecture possible dans ses diapositives d'APNIC 62. Il ne s'agit pas d'un remplacement universel déjà adopté par les navigateurs.

Un bilan d'incident devrait conserver séparément la décision de révocation, la publication par la CA, la version de la liste ou de la réponse accessible, les certificats encore servis aux différents points de présence et le résultat d'un client identifié. APNIC ne documente ici ni attaque contre une banque ni décompte de personnes lésées. L'essai établit une frontière de responsabilité plus précise : la décision de retirer la confiance n'est utile au lecteur que lorsqu'elle atteint le logiciel qui décide de sa connexion.

Sources