Confidentialité OCSP : le répondeur voit un certificat, pas votre URL

Une vérification de statut pose une question sur un certificat, et la réponse voyage sur sa propre connexion. Elle ne contient pas le chemin de la page qui a mené à la vérification. Les discussions sur la confidentialité traitent souvent cet échange comme un flux d’historique de navigation, ce qui surestime ce que porte la requête et sous-estime ce que le répondeur peut observer. Lisez la requête avant de décider de ce qu’elle révèle.

La requête identifie un certificat

L’identifiant de certificat OCSP est construit à partir d’une fonction de hachage, de deux hachages de l’émetteur et du numéro de série du certificat cible, comme le spécifie la RFC 6960. Chaque champ désigne un certificat, pas une URL ni une requête HTTP.

Le chemin de la page, la chaîne de requête et tout contenu de formulaire sont absents de l’identifiant standard. L’affirmation selon laquelle le répondeur reçoit l’URL exacte exige des preuves venant d’ailleurs que de la vérification du certificat. La requête nomme encore un certificat et un instant, et le répondeur peut savoir quel service le présente.

Ce qui manque, c’est la page, pas tout le contexte. Une vérification de certificat, plus un service connu, plus une source répétée peuvent être plus instructives que chacune d’elles prise seule.

Ce que le répondeur peut réellement observer

Le répondeur voit la connexion qui l’atteint : adresse source, horodatage et toutes les métadonnées de transport que son déploiement enregistre. Si la requête de statut suit le VPN, cette source peut être la sortie du VPN plutôt que le réseau d’accès de l’utilisateur. Ne supposez pas que la requête de statut emprunte le même chemin que la requête de page simplement parce que les deux appartiennent à une même session de navigateur.

Vérifiez le routage et le comportement de validation pris en charge par le client au lieu de les déduire d’une seule trace. Un tunnel divisé peut envoyer les deux requêtes dans des directions différentes.

La réponse agrafée est l’autre schéma courant. L’extension TLS status_request de la RFC 6066 permet à un serveur d’attacher une réponse OCSP à sa propre poignée de main, si bien que le client valide ce qui lui a été donné au lieu d’aller chercher lui-même le statut pour cette connexion. Ce déplacement change l’observateur. C’est le côté serveur qui effectue la récupération, et l’adresse propre du client n’atteint jamais le répondeur pour cette connexion.

Le statut peut arriver agrafé dans la poignée de main

Rien de tout cela ne garantit qu’un client ne fera jamais une autre requête de validation. La construction de la chaîne, la politique de statut et les mécanismes pris en charge varient selon l’implémentation.

Un visualiseur de certificats dans un navigateur ne décrit pas chaque système d’exploitation et client VPN. La même capture réseau peut signifier des choses différentes selon les paramètres de validation.

Le cache brise l’hypothèse d’une page pour une recherche

Le cache dissocie les chargements de page des recherches. Le navigateur peut réutiliser une réponse pendant un certain temps, donc une vue de page n’implique pas une requête réseau.

L’erreur inverse est tout aussi courante. Une réponse en cache ne dit rien sur le moment du prochain rafraîchissement, et le calendrier de rafraîchissement peut être sans rapport avec la page ouverte. Utilisez la documentation actuelle du client et la politique de validation en vigueur avant d’attribuer une capture à OCSP.

Une réponse de statut valide doit respecter les règles d’authenticité et de fraîcheur du vérificateur, et un HTTP 200 n’est pas la même chose qu’un bon statut. Un délai d’attente n’est pas une révocation. Ces issues conduisent à des comportements client différents et ne devraient pas être réduites à une seule erreur.

Des choix de confidentialité qui préservent la validation

Lorsque la recherche elle-même est sensible, discutez des options de livraison et de cache prises en charge avec le propriétaire du système. Ne le réglez pas en désactivant la vérification de révocation ou la validation de chaîne.

Une trace plus discrète n’est pas une connexion plus sûre. Gardez intactes l’identité du pair, la validation de chaîne et la politique de révocation prévue, et ne changez le chemin de livraison que par une option que le déploiement prend en charge. Consignez l’option choisie et son responsable.

Quand une recherche apparaît de façon inattendue, nommez séparément le destinataire, la route et l’opération de certificat. Un téléchargement d’émetteur, une requête de statut et la requête de page sont trois événements. Les traiter comme un seul rend l’examen de confidentialité inexact et masque quelle partie a réellement appris quelque chose. Partez des champs du protocole et progressez vers l’extérieur jusqu’au chemin réseau.