Le tiers qu’on ne contactait plus : ce que déplaçait l’agrafage OCSP

Résumé

• Une réponse OCSP signée pouvait accompagner le certificat présenté par le serveur. Celui-ci devenait son transporteur, sans acquérir le droit d’en définir le contenu ni de décider si le client devait l’accepter.
• La réutilisation économisait des échanges, au prix d’une gestion de la fraîcheur. Une déclaration inscrite dans le certificat pouvait rendre l’absence de réponse significative, mais liait alors le déploiement du certificat à la disponibilité des preuves attendues.

Le coût d’un détour

Une connexion à un site n’était pas nécessairement la dernière connexion nécessaire pour lui faire confiance. Lorsqu’un client devait consulter un service de statut, il ajoutait un tiers au chemin de vérification : un service à joindre, une réponse à attendre et une information supplémentaire sur la consultation à transmettre.

L’agrafage OCSP proposait de modifier ce trajet. Le serveur pouvait remettre au client une réponse de statut avec son certificat. Si cette réponse satisfaisait les vérifications requises, la consultation séparée devenait inutile. Le gain de confidentialité concernait cette requête évitée ; il ne transformait pas la navigation entière en activité anonyme.

Surtout, supprimer une connexion du visiteur ne supprimait pas le service qui produisait la réponse. Il fallait encore obtenir des réponses utilisables et les renouveler. Une partie du travail quittait le moment de la visite pour devenir une tâche d’exploitation du serveur.

Une idée antérieure à TLS 1.2

Le mécanisme figure déjà dans RFC 3546, publié en juin 2003. Le client pouvait demander un statut avec status_request et le serveur joindre une réponse OCSP à sa présentation du certificat. Le texte évoquait les réseaux contraints, les listes de révocation et les allers-retours économisés.

RFC 6066, de janvier 2011, reprenait cette extension dans le cadre ultérieur de TLS. La réponse encodée était transportée dans un message CertificateStatus, après le certificat. Ce n’était donc pas en 2011 que le principe avait été inventé, ni le dialogue TLS qui créait lui-même l’autorité de la réponse.

Cette précision historique évite de confondre l’apparition d’un format, son adaptation et son déploiement. Les RFC permettent de suivre les deux premières ; elles ne mesurent pas à elles seules la troisième.

Remettre une attestation n’est pas la signer

La difficulté paraît évidente : le site dont le certificat est examiné fournit lui-même le document censé rassurer le client. Le dispositif fonctionne parce que le client ne prend pas l’identité du livreur pour celle du signataire.

Selon RFC 6960, il doit notamment vérifier la correspondance avec le certificat, la signature, l’autorisation du signataire et la fraîcheur du statut. L’autorité de certification émettrice, un répondeur expressément reconnu ou un répondeur dûment désigné peuvent signer dans les conditions prévues. Posséder la clé TLS ordinaire du site ne confère pas cette fonction.

Le mot good exige la même prudence. La réponse positive à une question de statut n’établit pas nécessairement que le certificat a été émis. Elle ne certifie pas davantage que le site est inoffensif ou que toute la chaîne doit être acceptée. Le statut est une pièce du contrôle, pas un remplacement de tous les autres.

La séparation entre production, livraison et acceptation permet ainsi de faire circuler une preuve par un intermédiaire intéressé. Elle n’accorde pas à cet intermédiaire le droit de réécrire la preuve.

Le prix d’une réponse disponible d’avance

En septembre 2007, le profil léger défini par RFC 5019 organisait la production anticipée et la mise en cache des réponses OCSP. Une même réponse pouvait servir sans exiger un nouveau calcul et un nouvel échange à chaque utilisation.

Mais une réponse authentique peut avoir vieilli. thisUpdate situe le moment où le statut était connu comme exact ; producedAt celui de la signature ; nextUpdate indique quand des informations plus récentes seront disponibles au plus tard. Une signature récente ne signifie donc pas nécessairement une observation tout aussi récente.

Le profil léger impose nextUpdate et une vérification temporelle avec une horloge suffisamment exacte. OCSP de base permet que ce champ soit absent : les exigences d’un profil ne doivent pas devenir, dans le récit, une règle universelle. De même, une indication de cache HTTP non signée ne peut pas prolonger à elle seule l’acceptabilité du document signé.

La conséquence pratique est un amortisseur, pas une indépendance permanente. Des réponses déjà détenues peuvent rester utilisables pendant une indisponibilité du répondeur. Quand leur fraîcheur ne suffit plus, cette réserve est épuisée. Une révocation nouvelle ne modifie pas rétroactivement toutes les copies d’une ancienne réponse positive.

Faire du silence un écart à une promesse

Avec l’extension initiale, demander une réponse ne garantissait pas de la recevoir. L’absence pouvait signaler un serveur qui ne savait pas agrafer le statut, mais aussi un serveur qui préférait le taire. RFC 6066 signalait explicitement le cas d’un attaquant utilisant une clé compromise et prétendant ne pas prendre en charge l’extension.

Un client exigeant la validation OCSP devait alors interroger directement le service ou abandonner. Recevoir une réponse insatisfaisante constituait un autre cas, qui imposait l’arrêt de la négociation. Absence, statut inconnu, réponse périmée et révocation ne sont pas quatre façons de nommer la même observation.

En octobre 2015, RFC 7633 décrivait l’extension X.509 TLS Feature. En annonçant status_request dans le certificat, elle permettait à un client compatible de comparer le comportement du serveur à une attente authentifiée. C’est la base du mécanisme couramment appelé Must-Staple.

Le texte n’obligeait pas tous les clients à mettre en œuvre toutes les fonctions. Il conservait aussi des possibilités de validation par d’autres moyens. En revanche, le serveur présentant une telle déclaration devait pouvoir la respecter. Le document recommandait de ne pas activer un nouveau certificat avant que son jeton de statut soit disponible. Une promesse de sécurité devenait ainsi une contrainte de calendrier.

Ce qui resta lorsque le message changea

Avec TLS 1.3, spécifié en 2018, le statut est placé dans une extension de l’entrée du certificat concerné, et non dans l’ancien message séparé. Le contenant change ; le serveur n’en devient pas le signataire autorisé.

L’intérêt historique de l’agrafage tient à cette dissociation. Une preuve vérifiable peut emprunter un trajet moins coûteux sans céder son autorité au transporteur. Mais la preuve doit encore arriver à temps, concerner le bon certificat et rester assez récente. Le tiers évité pendant la visite demeure une dépendance dans la durée.

Sources

RFC 3546, RFC 6066, RFC 6960, RFC 5019, RFC 7633 et RFC 8446. L’analyse des responsabilités découle des mécanismes décrits, sans prétendre mesurer leur adoption actuelle.