web-dev-qa-db-fra.com

Dans quelle mesure les navigateurs actuels gèrent-ils la révocation des certificats?

Je suis un utilisateur de Firefox et suis récemment tombé sur le Liu, Yabing, et al. "Une mesure de bout en bout de la révocation des certificats dans l'ICP du Web." Conférence de mesure Internet 2015. ACM, 2015 étude et après un moment d'inquiétude, je me suis demandé si les vérifications des listes de révocation ou l'OCSP n'étaient toujours pas implémentées ou partiellement mises en œuvre dans la plus récente versions non seulement de Firefox mais aussi d'autres navigateurs. Même si j'ai exploré le Web pendant un certain temps à la recherche des dernières mises à jour en ce qui concerne la vérification des listes de révocation et OCSP (ma recherche se limitait principalement aux mises à jour de Firefox, je dois admettre), je n'ai rien trouvé de significatif.

Avez-vous des mises à jour récentes à ce sujet? Une grande partie du tableau ci-dessous (tiré de l'étude citée précédemment) resterait-elle barrée en rouge si l'évaluation était entièrement recommencée? J'ai l'impression qu'une telle réévaluation devrait être effectuée.

enter image description here

Une autre approche, adoptée par Chrome et Firefox par exemple, sont des ensembles CRL intégrés. À quelle fréquence sont-ils mis à jour et le délai de mise à jour de l'ensemble est-il suffisamment petit pour éviter la majorité des attaques?

8
Cobalt Scales

Pas très bien.

En théorie, le système devrait fonctionner. En pratique, ce n'est pas le cas. Les implémentations destinées à gérer la révocation - à savoir CRL et OCSP - ont toutes deux des problèmes. La plupart de cette réponse est basée sur cet article d'Alexey Samoshkin , ainsi que cet article de Scott Helme .

Qu'en est-il des CRL?

Une liste de révocation de certificats est un moyen remarquablement simple de déterminer si un certificat est valide ou non. Il s'agit essentiellement d'une liste de tous les certificats qui ont été révoqués. Si vous souhaitez vérifier si un certificat a été révoqué, vous devez vérifier la liste de révocation associée.

Cette liste est potentiellement très volumineuse, lente à télécharger et vous oblige à être en ligne afin de pouvoir vérifier la validité d'un certificat. Bien que l'exigence en ligne ne semble pas être un problème pour les navigateurs, il existe plus d'utilisations pour les certificats que pour authentifier un serveur Web, qui peut en effet être hors ligne.

Dans la pratique, les listes de révocation de certificats sont considérées comme un mécanisme obsolète qui génère beaucoup trop de frais généraux et est impossible à faire dans la pratique.

Et OCSP?

OCSP a été conçu pour être l'oie dorée qui résout tous les problèmes avec les listes de révocation de certificats. Dans la pratique, il a introduit un ensemble de nouveaux problèmes.

  • Latence accrue en raison de la nécessité de faire une demande en ligne au point de terminaison OCSP.
  • Dépendance de la disponibilité du point de terminaison OCSP.
  • Compromis de confidentialité pour l'autorité de certification, car vous devez transmettre pour quel certificat (et donc quels domaines) vous souhaitez avoir des informations OCSP.

Et les échecs?

Que se passe-t-il si un point de terminaison CRL ou OCSP n'est pas disponible? Il s'avère que rien. Si l'état du certificat ne peut pas être validé, les navigateurs les considèrent par défaut comme légitimes. Cela signifie qu'un attaquant peut réussir à faire en sorte que mon navigateur "renonce" à essayer d'obtenir des données OCSP (par exemple en supprimant tous les paquets destinés à aller vers un point de terminaison OCSP), même les certificats révoqués sont considérés comme valides.

Allons-nous jamais fixer la révocation ou devrions-nous simplement abandonner?

Il existe des tentatives pour atténuer ces problèmes. Chrome utilise CRLSet et Mozilla utilise OneCRL. L'idée est essentiellement que mon navigateur contient une liste de toutes les CRL et les met à jour périodiquement (par exemple une fois par jour).

Une autre tentative effectuée est OCSP Stapling, qui transfère à nouveau la charge de la preuve au serveur. L'idée est que le serveur demande périodiquement à l'autorité de certification si le certificat est toujours valide, puis obtient une réponse temporisée, que le serveur inclut avec le certificat.

Cela corrige plusieurs des problèmes mentionnés ci-dessus:

  • Le certificat et son état de révocation sont envoyés en une seule transmission, ce qui réduit la latence.
  • L'AC ne reçoit pas d'informations sur les domaines demandés par l'utilisateur.
  • Le point de terminaison OCSP de l'autorité de certification peut avoir une disponibilité réduite, car les messages sont valides pendant un certain temps.
  • Le point de terminaison OCSP a une charge inférieure, car il est davantage distribué entre les serveurs Web.

Alors, où est le piège?

J'ai mentionné que l'état actuel de la révocation des certificats est mauvais, donc il doit évidemment y avoir un problème. Il s'avère que les serveurs Web ne sont pas vraiment bons pour implémenter l'agrafage OCSP. Je n'entrerai pas dans tous les détails, car article d'Alexey fait un excellent travail pour l'expliquer. L'essentiel est que même s'ils sont activés, certains serveurs peuvent ne pas envoyer immédiatement des réponses agrafées. Certains serveurs, comme nginx, n'envoient pas de réponse si le certificat a été révoqué. Cela signifie que même si le serveur Web sait que le certificat est révoqué, il ne le dira pas à l'utilisateur car ... raisons?

Qu'en est-il de must-staple?

Heureux que vous ayez demandé! L'idée est simple, le certificat comprend un indicateur qui indique qu'un serveur doit agrafer une réponse OCSP, sinon la vérification échouera. Sonne bien en théorie, alors où est le piège?

Le hic, c'est que les navigateurs réagissent étrangement à ce drapeau. Firefox lance MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING, ce qui n'a de sens que lorsque vous savez déjà ce que cela signifie - à peine mieux que de nous lancer un T_PAAMAYIM_NEKUDOTAYIM . Chrome, d'autre part, ne s'en soucie pas du tout. Chrome ne prend pas du tout en charge OCSP, il est donc logique qu'une extension qui l'exige soit simplement ignorée.


En conclusion, la révocation du certificat est rompue et chacun de nous ne peut pas faire grand-chose pour y remédier.

5
MechMK1