Comment fonctionne l'agrafage OCSP?

Question

J'ai étudié agrafage OCSP pour HTTPS, ce qui semble assez intéressant. D'après ce que je peux dire, c'est essentiellement un moyen de décharger les listes de révocation de certificats de l'autorité de certification vers le serveur, ce qui permet de tout faire en une seule connexion, ce qui atténue certains problèmes de confidentialité. Comment fonctionne le processus dans une perspective de haut niveau?

Je suis principalement intéressé par:

• Où/comment l'agrafage OCSP est-il signalé comme activé? Est-ce quelque chose que l'AC fait?
• Comment le serveur obtient-il la CRL mise à jour de l'autorité de certification? Comment sait-il quand mettre à jour?
• Qu'est-ce qui empêche quelqu'un de retirer l'indicateur "OCSP est activé" de la poignée de main?
• Si la connexion SSL est compromise (par exemple via BEAST ou une fuite de clé privée), cela ouvre-t-il une possibilité pour l'attaquant de causer des problèmes à long terme en manipulant la CRL?

Answer 1

Un [~ # ~] crl [~ # ~] est un objet qui contient la liste des numéros de série des certificats qui ont été révoqués par une autorité de certification donnée . C'est un objet signé; l'émetteur de la liste de révocation de certificats est généralement l'autorité de certification elle-même (avec la même clé), mais ce pouvoir peut être délégué.

Une réponse OCSP est ce que renvoie un répondeur OCSP lorsqu'il reçoit une demande concernant l'état de révocation d'un certificat. Le protocole de demande/réponse est spécifié dans RFC 256 . Les réponses elles-mêmes sont signées par le répondant et elles peuvent avoir une vie indépendante; cela signifie qu'une réponse OCSP donnée peut être considérée comme une CRL spécialisée qui parle d'un seul certificat.

Lors de la validation du certificat , le vérificateur (par exemple un navigateur Web, lors de la validation du certificat du serveur) doit créer une chaîne de certificats, à partir de l'un de ses crust anchor (alias certificats racine), vérifiez toutes les signatures, noms et extensions, puis procède à la vérification statut de révocation de chaque certificat de la chaîne. Cette dernière étape consiste à obtenir des réponses CRL et/ou OCSP, à les valider (c'est-à-dire à vérifier les signatures) et à lire leur contenu. Cela soulève deux types distincts de questions:

1. Comment un vérificateur vérifie-t-il qu'une réponse CRL ou OCSP est authentique et à jour et s'applique vraiment au certificat en question?
2. Comment un vérificateur obtient-il la réponse CRL ou OCSP en premier lieu?

Correspondance CRL/OCSP avec un certificat

Concentrons-nous sur la configuration suivante: le vérificateur veut obtenir le statut de révocation du certificat [~ # ~] t [~ # ~] (en tant que "cible"). Il a déjà construit et vérifié une chaîne de certificats qui se termine par le certificat CA [~ # ~] c [~ # ~] suivi de [~ # ~] t [~ # ~], ce qui signifie que la signature sur [~ # ~] t [~ # ~] correspond à la clé publique dans [~ # ~] c [ ~ # ~]. De plus, l'état de révocation de [~ # ~] c [~ # ~] a été vérifié, et il est maintenant [~ # ~] t [~ # ~] qui intéresse le vérificateur. [~ # ~] t [~ # ~] peut être un certificat d'entité finale (par exemple le certificat du serveur SSL) ou un autre certificat CA comme partie d'une chaîne plus longue, qui s'étend au-delà de [~ # ~] t [~ # ~].

Une CRL est signée; qui signe qu'il s'agit d'une distinction subtile entre X.509 et son interprétation PKIX dans le contexte d'Internet . Pour le X.509 "original", une CRL est valide si elle est signée par une entité qui possède un certificat valide et porte le même Nom unique que l'AC. Cela fonctionne bien si la CRL est signée par la même clé publique que [~ # ~] t [~ # ~], c'est-à-dire la clé de l'AC [~ # ~] c [~ # ~]: à ce stade, [~ # ~] c [~ # ~] est un certificat entièrement validé de sorte que sa clé publique peut être "de confiance" (le vérificateur est raisonnablement sûr que la clé publique appartient vraiment à une entité qui porte le nom donné dans [~ # ~] c [~ # ~]'s subjectDN champ). Cependant, il peut s'agir de tout autre certificat portant ce nom et situé à la fin d'une chaîne valide qui lui est propre (ce qui peut impliquer davantage de création de chemin, de validation et de traitement de la liste de révocation de certificats). Dans X.509, les noms distinctifs sont tout, car X.509 était destiné au Annuaire, l'agrégat mondial de serveurs de type LDAP où tout est uniquement référencé par son nom distingué.

PKIX, le groupe de travail qui s'occupe d'Internet, a remarqué que l'Annuaire, aussi merveilleux soit-il, partage certaines caractéristiques avec des bêtes mythiques comme les Mokèlé-mbèmbé , en particulier qu'il ne semble pas exister pas du tout (au moins, aucune observation confirmée n'a été signalée). De même, PKIX applique une restriction pour limiter les problèmes: le certificat de l'émetteur de la liste de révocation de certificats doit se trouver à la fin d'un chemin qui commence par la même ancre de confiance que le chemin qui se termine par [~ # ~] t [~ # ~]. Cela devrait éviter les problèmes de trans-racine lorsque deux AC distinctes qui ne se connaissent pas ont fini par utiliser les mêmes noms distinctifs (ils auraient pu remarquer le problème tout de suite s'ils avaient travaillé dans le contexte de l'annuaire, s'il avait existé). Ce point spécifique se trouve dans RFC 528 , section 6.3.3, étape (f).

Le rôle d'émetteur CRL peut être délégué, auquel cas le nom distinctif de l'émetteur CRL se trouve dans le CRL Distribution Points extension dans [~ # ~] t [~ # ~] lui-même, et un Issuing Distribution Point l'extension se trouve dans la CRL.

Pour les réponses OCSP, un système similaire est utilisé. La réponse OCSP peut être signée par l'AC elle-même (avec la clé dans [~ # ~] c [~ # ~]); ou il peut y avoir un émetteur dédié. Les choses y sont plus contraintes: quand il y a un émetteur dédié, il doit avoir un certificat qui est directement émis par [~ # ~] c [~ # ~] lui-même, et portant une extension spécifique qui le marque comme répondeur OCSP (Extended Key Usage avec le id-kp-OCSPSigning OID, voir la section 4.2.2.2 de RFC 256 ). Le certificat de ce répondeur peut être attaché à la réponse OCSP elle-même (en dehors de la zone signée, mais néanmoins codé dans le même blob).

Le point important est que peu importe la façon dont la réponse CRL ou OCSP a été obtenue: ce sont des objets signés, la vérification des signatures et tout le contenu correspondant et l'extension sont suffisants. L'objet lui-même peut voyager sur TCP, courriels, clés USB, caravanes de chameaux, appris par cœur et déclamé par un acteur shakespearien, peu importe. La signature résume ces détails. Certificats, CRL, Les réponses OCSP ne peuvent pas être "manipulées" sans invalider la signature.

Les réponses CRL et OCSP ont dates de validité . Ils ont tous deux un champ thisUpdate qui indique quand ils ont été émis (officiellement, la date à laquelle les informations qu'ils contiennent ont été recueillies). Ils ont également un champ nextUpdate qui est la date avant laquelle une version plus récente doit être publiée; ainsi, il sert comme une sorte de date d'expiration. Il est prévu que les vérificateurs mettent en cache les réponses CRL et OCSP, en utilisant ces dates pour savoir si la version en cache est toujours utilisable, ou si une nouvelle doit être obtenue.

Comment localiser les réponses CRL et OCSP

La façon dont une réponse CRL ou OCSP est distribuée n'est pas importante pour security, mais, bien sûr, un vérificateur ne peut pas deviner l'URL à partir de rien. L'URL à laquelle la CRL peut être téléchargée est codée dans le CRL Distribution Points extension du certificat [~ # ~] t [~ # ~] (cette extension a deux rôles: un rôle de validation pour la délégation du pouvoir d'émission des CRL et un rôle descriptif pour donner des pointeurs vers des emplacements où la CRL réelle peut être téléchargée). http:// Les URL sont courantes, mais aussi ldap:// URL (en particulier dans un environnement fermé comme les réseaux d'entreprise). Une https:// L'URL pour le téléchargement de la liste de révocation de certificats peut entraîner une boucle (car le téléchargement implique la validation du certificat d'un autre serveur SSL), par conséquent, elle aura tendance à ne pas être bien prise en charge, ou pas du tout (Windows ne suivra pas une telle URL).

De même, l'URL à laquelle un répondeur OCSP peut être trouvé se trouve dans le Authority Information Access extension dans le certificat [~ # ~] t [~ # ~].

Ces URL sont à titre indicatif seulement; le vérificateur peut utiliser toute réponse CRL ou OCSP qu'il pourrait obtenir, quelle que soit sa provenance, à condition que toutes les signatures soient vérifiées. Étant donné que les réponses CRL et OCSP ont une durée de vie non négligeable, il est logique de les mettre en cache et de les réutiliser. L'agrafage OCSP est un moyen pour un SSL serveur d'obtenir des réponses OCSP pour son propre certificat et de les fournir au client, sous l'hypothèse que le client peut en avoir besoin. Cela rend l'ensemble du processus plus efficace: le client n'a pas à ouvrir de connexions supplémentaires pour obtenir lui-même les réponses OCSP, et la même réponse OCSP peut être envoyée par le serveur à tous les clients dans un délai donné. Une façon de le voir est que le serveur SSL agit comme un proxy Web dans le but de télécharger les réponses OCSP.

L'agrafage OCSP dépend entièrement du serveur SSL; le contenu des certificats et des réponses OCSP n'est pas affecté. L'AC ou le répondeur OCSP n'ont pas besoin de savoir que l'agrafage se produit du tout.

"Supprimer" l'indicateur d'agrafage OCSP de la prise de contact romprait les messages Finished à la fin de la prise de contact, donc cela n'est pas possible pour l'attaquant, à moins que cela ne lui permette de rompre la prise de contact entière avant la fin. Cependant, ce n'est pas le cas: le manque d'agrafage OCSP ne signifie pas que le client ne vérifiera pas l'état de révocation; cela signifie simplement que le client sera seul et devra obtenir lui-même les réponses CRL ou OCSP.

Le malheur de l'agrafage OCSP est qu'il n'est pas encore largement pris en charge. L'idée est cependant valable. Ses implications en termes de sécurité sont qu'avec l'agrafage, un serveur SSL a un argument puissant pour convaincre le navigateur Web de réellement faire son travail et de ne pas ignorer complètement les vérifications d'état de révocation, comme de nombreux navigateurs Web sont malheureusement enclins à faire (les choses changent en la matière, mais lentement).

Remarque: La durée de vie des réponses CRL/OCSP varie généralement de quelques minutes à quelques jours. Les dates sont vérifiées par rapport à la notion de temps client; les clients avec des horloges obsolètes peuvent rencontrer des problèmes.