La publication de listes de révocation de certificats sur HTTP est-elle une vulnérabilité potentielle?
J'ai remarqué qu'au moins une autorité de certification majeure (Comodo) publie sa CRL sur HTTP plutôt que HTTPS.
Cela me semble être quelque peu une vulnérabilité, car un attaquant pourrait détourner la connexion HTTP qui cherche à télécharger la CRL et quand HSTS est en cours d'utilisation au tout au moins exécuter ce qui équivaut effectivement à une attaque DoS sur le domaine. (Parce qu'avec HSTS actif, les navigateurs ne devraient pas permettre à l'utilisateur de contourner l'avertissement de certificat non valide; voir RFC 6797 section 8.4 et section 12.1 .)
Alors que les CRL sont normalement signées , et il semblerait que toute implémentation saine devrait rejeter une CRL signée qui ne passe pas la validation de la signature, je n'ai vu aucun moyen de déterminer le signataire de la CRL dans n'importe quel site Web navigateur, donc même signer une CRL de remplacement avec votre propre clé de certificat racine semble être une opération relativement à faible risque. Et cela suppose bien sûr que le navigateur nécessite que la CRL soit signée en premier lieu; sinon, vous pouvez simplement le remplacer par une liste de révocation de certificats non signée. (Et bien sûr, si l'implémentation rejette une CRL signée qui échoue à la validation de la signature, ou même des CRL non signées, il devient trivial de tromper l'UA à utiliser un certificat qui a été révoqué mais qui n'a pas encore atteint sa date d'expiration.)
S'agit-il d'un problème potentiel réel? Quels contrôles sont normalement effectués par les agents d'utilisateur en ce qui concerne les listes de révocation de certificats pour éviter qu'elles ne deviennent un problème réel?
Il n'existe pas de liste de révocation de certificats non signée; le champ de signature est obligatoire, et tout système utilisant la CRL vérifiera la signature.
Dans X.509 pur , une CRL sera considérée comme "acceptable" comme source d'informations sur le statut de révocation d'un certificat donné [~ # ~] e [ ~ # ~] s'il est signé par un "émetteur de révocation autorisé": la signature de la CRL doit correspondre à la clé publique contenue dans un certificat déjà validé, dont subjectDN est égal à le issuerDN de [~ # ~] e [~ # ~] (vous pouvez avoir un DN distinct si [~ # ~] e [~ # ~] contient l'extension de point de distribution CRL appropriée et la CRL a une extension de point de distribution d'émetteur correspondante, mais oublions cette complexité supplémentaire). Les règles complètes sont exposées dans section 6. . Notez que "X.509 pur" est censé fonctionner dans le contexte de l'annuaire, le genre de serveur LDAP mondial qui référence tout sous des noms uniques sans ambiguïté.
Étant donné que l'annuaire ne fonctionne pas vraiment, car il n'existe pour ainsi dire pas du tout, les implémentations existantes ont tendance à implémenter des règles plus strictes et plus simples. De manière générale, un navigateur Web validant un certificat [~ # ~] e [~ # ~] émet par CA [~ # ~] c [~ # ~] n'acceptera une CRL que si elle est également signée par la même autorité de certification, avec la même clé. Cette règle maintient la validation de chemin d'accès simple et limitée (sinon, vous pouvez imaginer une situation où vous devez obtenir une liste de révocation de certificats pour chaque certificat dans le chemin, et chaque liste de révocation de certificats doit être vérifiée par rapport à un autre certificat émetteur de liste de révocation de certificats qui nécessite sa propre validation de chemin, etc.) sur). Par conséquent, il est peu probable que la production de votre propre CRL par rapport à votre propre autorité de certification racine ait un effet réel.
Les CRL, comme les certificats, sont donc des objets qui sont toujours signés et jamais utilisés sans vérifier cette signature (*), afin qu'ils puissent être servis sur HTTP simple. L'utilisation de HTTPS pour servir la liste de révocation de certificats n'est qu'un gaspillage de ressources; cela peut même empêcher le téléchargement de CRL de fonctionner car certaines implémentations (par exemple Windows) refusent de suivre l'URL HTTPS lors de la validation des certificats (que ce soit pour CRL, OCSP ou téléchargement CA intermédiaire supplémentaire), car cela signifierait SSL, puis un autre certificat à valider, et éventuellement une boucle sans fin.
(*) J'exclus ici les "certificats" d'autorité de certification racine, traditionnellement auto-signés; ce ne sont pas de vrais certificats au sens X.509, mais seulement des objets qui imitent les règles de codage des certificats.
À propos de l'attaque de réexécution, la CRL est horodatée avec date de génération et date de la prochaine mise à jour . La date nextUpdate est obligatoire dans le profil PKIX. Si un certificat est révoqué, l'ancien CRL peut être rel avant nextUpdate si un canal non sécurisé est utilisé.
Je voudrais juste ajouter que certains (au moins) navigateurs Mozilla ont une variable de configuration: security.OCSP.require (voir IRL about: config) qui est, par défaut, définie sur false.
Il semble que si security.OCSP.require est défini sur "false", le navigateur devrait se replier sur la vérification de la CRL à l'URI du point de distribution CRL nommé, qui est par coïncidence le même URI utilisé dans le champ d'accès aux informations d'autorité où vraisemblablement la signature du CA et du CRL.
Empiriquement (au moins sous Linux) si cette URL est bloquée, au moins les navigateurs Mozilla (Firefox, Sea Monkey, Chrome) transmettront le certificat sans vérifier s'il a été révoqué et remplacé.
J'ai du mal à comprendre comment cela ne serait pas une vulnérabilité mais ce n'était pas le nœud de la question d'origine.
Pour info: sous Windows, les paramètres CRL et OCSP semblent être fonction de la stratégie de groupe (stratégie de l'ordinateur local, configuration de l'ordinateur, paramètres Windows, paramètres de sécurité, stratégies de clé publique) et peuvent être configurés, mais au moins à partir de Windows 2003 don ne semblent pas être configurés par défaut. Sur Mac, cela pourrait être encore atténué par le trousseau, pour ceux qui ont tendance à faire confiance à un tiers avec leurs mots de passe ....