Dans quelle mesure est-il possible de pirater une autorité de certification? Quels certificats racine de confiance par défaut dois-je supprimer?
Cette question a été révisée et clarifiée de manière significative depuis la version originale.
Si nous examinons chaque certificat approuvé dans mon magasin racine de confiance, combien dois-je leur faire confiance?
Quels facteurs doivent être pris en considération lorsque j'évalue la confiance de chaque autorité de certification racine pour une suppression potentielle de mon magasin local?
Plus d'informations:
Si une autorité de certification délivre un certificat à une partie incorrectement validée, toutes les machines qui font confiance à cette autorité de certification sont vulnérables aux attaques MITM. Par conséquent, toutes les autorités de certification valident rigoureusement le demandeur d'une demande de certificat SSL donnée pour garantir l'intégrité de leur chaîne CS.
Cependant, une grande partie de ce processus de vérification de l'AC est soumise à une intervention humaine et offre la possibilité d'émettre un certificat à la mauvaise partie. Cela peut être dû à une erreur de l'opérateur CA, aux demandes du gouvernement ou peut-être à la contrainte (pot-de-vin) d'un opérateur CA.
J'aimerais en savoir plus sur les autorités de certification par défaut les plus susceptibles d'émettre des certificats à la mauvaise partie. J'ai l'intention d'utiliser ces informations pour conseiller aux utilisateurs de supprimer cette autorité de certification de leur magasin de certificats de confiance
Exemples:
Supposons que le gouvernement contrôlant une autorité de certification particulière veuille assumer l'identité de Microsoft.com et demande une exception au processus de vérification de l'autorité de certification. Ce gouvernement exige alors également que le secret de cette exception soit maintenu. La paire de clés générée serait ensuite utilisée dans une attaque MITM.
Approbation par défaut de Windows Azure
Windows Azure prend en charge 275 autorités de certification, comme indiqué dans le lien suivant . Selon l'utilisation de l'autorité de certification particulière, certaines de ces autorités de certification peuvent augmenter la surface d'une attaque particulière. En fait, cela peut être techniquement nécessaire pour que certaines applications fonctionnent correctement.
Amazon Default Trust
(non disponible) Veuillez partager des liens vers Amazon, Google et la liste d'autorités de certification par défaut de VMWare si vous les rencontrez.
Mozilla
Un liste de tous les certificats et déclarations d'audit est disponible.
Apple iOS
Liste de tous certificats racine iPhone comme mentionné dans cette # WWDC2017. Vidéo
Mise à jour 5 Le problème racine (heh) avec le modèle CA est qu'en général, toute CA peut émettre des certificats pour n'importe quel domaine, vous êtes donc vulnérable au maillon le plus faible. Quant à qui vous pouvez faire confiance, je doute que la liste soit très longue, car les enjeux sont élevés et la sécurité difficile. Je recommande la publication de Christopher Soghoian sur le sujet, qui clarifie les différentes approches que les gouvernements du monde entier ont utilisées pour accéder aux données des utilisateurs privés - que ce soit en les demandant directement aux entreprises qui exploitent des services cloud, via l'écoute électronique, ou de plus en plus maintenant via la coercition CA ou hacks: légère paranoïa: les forces qui ont conduit au hack DigiNotar .
Ici, je fournis quelques détails et je termine par des liens vers des correctifs potentiels.
En 2009, Etisalat (détenu à 60% par le gouvernement des Émirats arabes unis) a déployé un correctif BlackBerry d'apparence anodine qui insérait des logiciels espions dans les appareils RIM, permettant la surveillance des e-mails, de sorte qu'il peut difficilement être considéré comme fiable. Mais il figure dans de nombreuses listes de CA de confiance: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars
Mise à jour 1 Voir aussi un exemple d'une attaque réussie, prétendument par un Iranien nommé ComodoHacker , contre Comodo: Certificats SSL escrocs ("case comodogate") - F-Secure Weblog . F-Secure note que Mozilla comprend des certificats délivrés par des autorités de certification en Chine, Israël, Bermudes, Afrique du Sud, Estonie, Roumanie, Slovaquie, Espagne, Norvège, Colombie, France, Taïwan, Royaume-Uni, Pays-Bas, Turquie, États-Unis, Hong Kong, Japon , Hongrie, Allemagne et Suisse.
La Tunisie est un autre pays qui gère une autorité de certification largement reconnue, et il existe également une bonne documentation sur les actions de leur gouvernement pour envahir la vie privée: L'histoire intérieure de la façon dont Facebook a répondu aux hacks tunisiens - Alexis Madrigal - Technologie - L'Atlantique
Mozilla note une autre pratique douteuse à surveiller: les autorités de certification qui permettent à un partenaire RA d'émettre des certificats directement à partir de la racine, plutôt que via un intermédiaire: Problème de certificat Comodo - Suivi sur le blog de sécurité de Mozilla .
Voir aussi plus de détails, y compris les spéculations sur la revendication de responsabilité par un pirate informatique iranien isolé Les navigateurs Web et Comodo divulguent une attaque réussie de l'autorité de certification, peut-être d'Iran | La liberté de bricoler
Mise à jour 3 : Une autre attaque réussie apparemment également par ComodoHacker était contre le DigiNotar CA. Leur site Web a été compromis à partir de 2009, mais cela n'a été remarqué qu'après que DigiNotar a également été utilisé en 2011 par des Iraniens pour signer de faux certificats pour les sites Web de Google, Yahoo !, Mozilla, WordPress et The Tor Project. DigiNotar n'a pas révélé sa connaissance de l'intrusion dans son site depuis plus d'un mois. Voir plus sur DigiNotar Hack souligne les échecs critiques de notre modèle de sécurité Web SSL | Freedom to Tinker .
Je suppose que la plage de vulnérabilité de diverses autorités de certification varie assez largement, tout comme leur utilité. Je suggère donc de recentrer votre stratégie. Lorsque vous pouvez le restreindre à des actifs spécifiques que vous essayez de protéger, supprimez simplement toutes les autorités de certification, à l'exception de celles nécessaires à l'utilisation de ces actifs. Sinon, envisagez d'éliminer les autorités de certification que vous jugez les plus vulnérables à ceux qui se soucient de vos actifs, ou les moins populaires, simplement pour réduire la surface d'attaque. Mais acceptez le fait que vous resterez vulnérable aux attaques sophistiquées, même contre les autorités de certification les plus populaires et les plus prudentes.
Mise à jour 2 : Il existe un excellent article sur la réparation de notre infrastructure de CA dangereuse chez Freedom to Tinker: Construire une meilleure infrastructure de CA
Il parle de ces innovations:
Mise à jour 4 Un de nos articles de blog sur la sécurité informatique en août 2011 couvre également le cas pour passer à DNSSEC: n regard basé sur les risques pour résoudre le problème le problème de l'autorité de certification "Stack Exchange Security Blog
Mise à jour 6 Plusieurs autorités de certification ont été prises en train de violer les règles. Cela inclut l'agence française de cyberdéfense (ANSSI) et Trustwave, dont chacun était lié à l'usurpation de certificats numériques .
Mise à jour 7 Encore un autre ensemble de "certificats émis de manière erronée", via le contrôleur indien des autorités de certification (Inde CCA) en 2014: Google Online Security Blog: Maintenir la sécurité des certificats numériques
Voir également la question sur Transparence des certificats qui ressemble à une approche utile pour découvrir les mauvais certificats et les violations de stratégie plus tôt.
Comme Matt Blaze l'a écrit une fois, les autorités de certification vous protègent de toute personne dont elles ne veulent pas prendre de l'argent. Cela devrait vous indiquer où se trouvent les incitations de l'AC et certains risques potentiels dans l'arrangement.
Je crains que la réponse courte à cette question soit qu'il soit impossible de savoir, pour autant que je puisse voir. Il existe un grand nombre d'autorités de certification par défaut installées dans la plupart des navigateurs courants et il est difficile d'évaluer leur probabilité d'être "dignes de confiance" en termes de remise de certificats à des organisations gouvernementales ou autres.
Si une autorité de certification devenait non fiable, elle serait probablement supprimée des listes d'installation par défaut des navigateurs (selon @xce ci-dessous, Diginotar est un bon exemple ici et aussi Digicert)
En plus de l'organisation fournissant des certificats volontairement, il existe un risque qu'ils fournissent des certificats sans effectuer les contrôles de sécurité appropriés sur le demandeur. Chez Defcon, il y a quelques années, plusieurs présentations ont eu lieu sur le thème de l'obtention de certificats sans autorisation.
S'il s'agit d'une préoccupation importante, la seule façon d'y penser serait de créer une liste blanche des autorités de certification que vous avez examinées et qui sont à l'aise avec la sécurité fournie. Évidemment, cela ne fonctionnerait pas pour accéder à Internet en général, car vous finiriez probablement par supprimer les autorités de certification qui ont des problèmes de certificats pour les sites que vous souhaitez utiliser.
2 exemples qui vont au cœur de ce que vous devez savoir, mais pas ce que vous demandez explicitement:
- Il y a plusieurs années (2006, ou peut-être fin 2005), il y a eu un incident de phishing SSL assez bien connu - un faux site Web de banque a reçu un certificat SSL légitime (de GeoTrust, je crois), pour une faute d'orthographe sur le site d'une banque régionale. (Mise à jour: trouvé ce lien historique - l'adresse était pour le nom complet de la banque au lieu de l'acronyme abrégé). Depuis lors, il y a eu d'autres cas de phishing SSL ... Il est possible d'obtenir un certificat sans recourir à la "coercition".
- La récente Stuxnet novella s'appuyait, entre autres tactiques, sur des certificats volés. Ceux-ci ont été "empruntés" à des fabricants de pilotes tiers et, comme ils étaient "fiables", ont pu être utilisés à mauvais escient afin de planter le logiciel malveillant.
Ensuite, bien sûr, il y a les scénarios logiciels où l'autorité de certification n'est même pas mise en service - par exemple avec des clients lourds qui appellent Web Services, qui ne se soucient pas de valider le certificat du serveur ....
Mon point est que si vous vous inquiétez du MITM sur SSL, le plus souvent, ce n'est pas la contrainte gouvernementale qui devrait vous inquiéter. Il existe généralement des moyens plus faciles et plus accessibles.
Je m'oppose même à ce que "Trusted Certs" soit appelé "Trusted" ... Ce n'est pas parce que je sais qui vous êtes que je devrais vous faire confiance ... et cela ne veut pas dire que je devrais faire confiance que vous savez qui quelqu'un sinon est.
Sans oublier que si vous supprimez les certificats racine standard du magasin de confiance, de nombreux sites sur Internet ne fonctionneront pas comme prévu.
D'un autre côté, si vous avez affaire à un serveur/appareil qui n'a pas besoin de capacités de navigation générales, mais communique avec un serveur spécifique (ou serveurs), supprimez définitivement [~ # ~] tous les [~ # ~] root certs, à l'exception d'une liste blanche de ceux dont vous avez besoin.
Et si vous optez pour votre propre autorité de certification interne, c'est encore mieux ...
Chaque autorité de certification publie une déclaration de pratique de certificat qui décrit comment elle protège ses propres clés et valide les demandes de certificats avant de les émettre. Une URL vers l'emplacement de ce document est généralement intégrée dans chaque certificat émis par l'autorité de certification. En supposant que l'autorité de certification en question suit réellement ce document de politique, elle devrait vous donner une indication de la longueur à laquelle elle se rend pour vérifier la validité de l'entité demandant des certificats. Recherchez les déclarations selon lesquelles elles protègent leurs clés de signature d'autorité de certification à l'aide de modules de sécurité matérielle ou de modules cryptographiques pour protéger les clés de signature, l'authentification multifacteur et l'autorisation basée sur le quorum pour signer les certificats, etc. Ces méthodes de protection rendent la tâche beaucoup plus difficile et plus coûteuse. pour un tiers voyou pour voler les clés de signature.
L'énorme liste d'autorités de certification de confiance (mon trousseau de racines système Mac en compte 175) est là pour votre commodité, pour rendre le système HTTPS utilisable pour vous et tous les habitants de la planète qui ne posent pas ces questions. Vous pouvez, bien sûr, exclure chaque autorité de certification de cette liste, sauf si vous avez personnellement audité leurs pratiques. Pour un système fermé, où vous contrôlez tous les points de terminaison et où vous avez un nombre limité de parties de confiance, cela est faisable. Le système de contrôle de version Subversion n'inclut aucun certificat racine de confiance, mais vous pouvez ajouter le vôtre à chaque client. Pour le Web dans son ensemble, le seul moyen que nous avons trouvé pour le rendre utilisable est d'avoir une partie de confiance hors bande (la société qui fournit votre système d'exploitation ou votre navigateur, quoi que vous en pensiez) fournissant une liste de des certificats qui vous permettent de vous connecter à presque tous les serveurs SSL dans le monde.
Avez-vous vraiment besoin de tous ces certificats dans votre liste de confiance? Probablement pas. Mais votre fournisseur de système d'exploitation/navigateur ne peut pas anticiper (et ne devrait pas contrôler) avec qui vous voulez faire des affaires, ils les incluent donc tous. Le problème avec la grande liste est que vous avez des AC de tout plumage, avec toutes sortes de méthodes de vérification, de toutes les juridictions, traitées exactement de la même manière. Toutes les autorités de certification n'agissent pas de la même manière: nous avons vu des cas de données d'identification de connexion de revendeur compromises, et même de clés d'autorité de certification compromises. Certains CA exigent un certificat de constitution et la promesse de votre premier-né, d'autres vérifient simplement que vous pouvez recevoir des e-mails sur le domaine pour lequel vous demandez un certificat. Et pourtant, chaque autorité de certification est traitée exactement de la même manière par votre navigateur.
Une ligne de défense contre les certificats malveillants pour le même nom commun serait de mettre en cache le certificat d'origine sur le client: si un certificat différent d'une autre autorité de certification apparaît soudainement, cela devrait être source de préoccupation. Je ne sais pas comment les navigateurs d'aujourd'hui traitent ce cas, et je suis trop paresseux pour le savoir.
Ce genre de discussion me rappelle toujours ce bug Mozilla demandant l'inclusion d'une nouvelle autorité de certification. Assez hilarant, mais assez perspicace.
Lorsque vous recherchez le certificat à supprimer sur un PC Windows, vous devez d'abord vous assurer de ne pas supprimer les certificats requis par le système. Si vous essayez de le faire, vous obtiendrez le message d'erreur suivant
Il s'agit de l'URL avec une liste de certificats qui ne doivent jamais être supprimés d'un système Windows http://support.Microsoft.com/?id=293781
Ensuite, vous devriez envisager de supprimer (tester la suppression de) les certificats intermédiaires, car ils n'existent que " niquement pour des raisons héritées ".
Lors de l'évaluation de la suppression de tous les certificats restants, considérez que le Microsoft Root Certificate Program requiert que l'autorité de certification passe l'une de ces normes d'audit:
- ETSI 102 042
- ETSI 101 456
- WebTrust pour les autorités de certification
- Audits de préparation WebTrust EV
- ISO 21188 (Notez qu'ils n'acceptent pas ISO 27001)
Si vous supprimez des certificats d'un navigateur non MSFT (IE), vous souhaiterez peut-être consultez ces consignes de qualité CA .
Restrictions
Le programme comporte également des audits supplémentaires qui s'appliquent à l'utilisation des clés. L'utilisation des clés est limitée aux éléments suivants:
Authentification du serveur (SSL) = 1.3.6.1.5.5.7.3.1
Authentification client (SSL) = 1.3.6.1.5.5.7.3.2
E-mail sécurisé (SMIME) EKU = 1.3.6.1.5.5.7.3.4
Signature du code EKU = 1.3.6.1.5.5.7.3.3
Horodatage EKU = 1.3.6.1.5.5.7.3.8
OCSP EKU = 1.3.6.1.5.5.7.3.9
Système de fichiers de chiffrement EKU = 1.3.6.1.4.1.311.10.3.4
IPSec (Tunnel, User) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7
Utilisations clés interdites
Les utilisations clés suivantes sont interdites par le programme:
Ouverture de session par carte à puce Il s'agit d'un scénario d'entreprise uniquement, car le déploiement d'Active Directory est requis et la racine doit être ajoutée au magasin NTAuth dans Active Directory. Consultez l'article KB suivant pour plus de détails. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245
Droits numériques Cette EKU est obsolète. Windows Media DRM utilise son propre format XML pour les licences et n'utilise pas X.509.
Subordination qualifiée Cette EKU est obsolète et est ignorée par Windows.
Scénario CA de récupération de clé d'entreprise.
Récupération de fichiers Cette EKU est obsolète et est ignorée par le système de fichiers de cryptage Windows (EFS).
Toutes les politiques d'application Nous ne pouvons pas accorder "toutes les utilisations" car cela admet nécessairement les EKU uniquement pour l'entreprise et autres inacceptables.
Réplication de messagerie du service d'annuaire Scénario d'entreprise
Agent de demande de certificat
Scénario d'autorité de certification d'entreprise
Scénario CA de l'agent de récupération de clé
Certificat de chiffrement CA
Scénario d'autorité de certification d'entreprise
Critères d'acceptation
De plus, les critères suivants doivent être remplis avant d'ajouter une AC à usage général ou gouvernemental à la racine:
L'AC doit fournir les informations demandées ci-dessous (voir Étape 1. Contacter Microsoft ) et recevoir l'approbation préalable pour devenir membre du programme.
L’AC doit fournir un certificat de test émis à partir du certificat racine de l’AC à des fins de test. Facultativement, une autorité de certification peut fournir à Microsoft l'URL d'un serveur accessible au public où les certificats émis à partir de leur certificat racine peuvent être vérifiés. (Voir FAQ pour plus de détails)
L'autorité de certification doit remplir un contrat Microsoft CA. L'accord ne sera fourni qu'après avoir terminé l'étape 1 du processus de demande et reçu l'approbation préliminaire de votre demande.
Les certificats racine doivent être conformes à la section des exigences techniques ci-dessous. En particulier, nous avons besoin d'une taille de clé de chiffrement minimale de module RSA 2048 bits pour toute racine et toutes les autorités de certification émettrices. Microsoft n'acceptera plus les certificats racine avec le module RSA 1024 bits de toute expiration. Nous préférons que les nouvelles racines soient valides pendant au moins 8 ans à compter de la date de soumission mais expirent avant l'année 2030, surtout si elles ont un module RSA de 2048 bits.
Les certificats émis à partir d'un certificat racine doivent prendre en charge l'extension de point de distribution CRL. Le point de distribution CRL doit pointer vers un emplacement accessible au public.
L'AC doit avoir une politique de révocation documentée et elle doit pouvoir révoquer tout certificat qu'elle émet.
L'AC doit effectuer un audit et soumettre les résultats de l'audit à Microsoft tous les douze (12) mois. L'audit doit couvrir l'intégralité de la hiérarchie PKI qui sera activée par Microsoft via l'attribution des utilisations de clés étendues (EKU). Toutes les utilisations de certificats que nous activons doivent être auditées périodiquement. Le rapport d'audit doit documenter l'étendue complète de la hiérarchie PKI, y compris toute sous-autorité de certification qui délivre un type spécifique de certificat couvert par un audit. Les audits éligibles comprennent:
WebTrust for Certificate Authorities v1.0 ou version ultérieure , complété par un auditeur WebTrust for CA agréé,
ISO 21188: 2006 , "Infrastructure à clé publique pour les services financiers - Pratiques et cadre stratégique", complétée soit par un auditeur WebTrust pour CA agréé, soit par une autorité d'audit opérant conformément aux lois et politiques des évaluateurs dans la même juridiction que l'AC.
Ce sont les vérifications acceptées à l'heure actuelle pour les AC non gouvernementaux. Nous nous réservons le droit de modifier les audits énumérés ci-dessus et/ou d'accepter d'autres audits comparables à l'avenir.
Exigences techniques
Les nouveaux certificats racine doivent répondre aux exigences techniques suivantes:
Les certificats racine doivent être des certificats x.509 v3.
Le nom du sujet doit contenir un nom significatif de l'AC (ex. Ne peut pas être "Root" ou "CA1")
Extension des contraintes de base: cA = true
Utilisation des clés (le cas échéant): keyCertSign et cRLSign uniquement
Les exigences relatives aux tailles de clé racine sont basées sur NIST SP 800-57:
RSA greater or equal to 2048-bit modulus ECC greater or equal to P256 modulusL'algorithme de hachage doit être au moins SHA1. Aucun hachage MD2, MD4 ou MD5 n'est accepté.
Pour une taille de clé racine supérieure ou égale à un module RSA 2048 bits, le certificat racine ne doit pas expirer avant au moins 8 ans après la soumission et au plus tard en 2030. Une expiration plus longue peut être accordée à des tailles de clé racine plus grandes.
Les certificats d'autorité de certification intermédiaires sont exclus du programme d'autorité de certification racine (voir la foire aux questions pour plus d'informations)
L'AC n'émettra pas de certificats MD2, MD4 ou MD5 d'entité subordonnée ou finale à partir d'un certificat racine distribué par le programme, à compter du 15 janvier 2009.
Les certificats racine RSA 1024 bits existants ("hérités") peuvent rester distribués par le programme jusqu'à la date limite NIST du 31 décembre 2010, sauf disposition contraire de Microsoft.
L'autorité de certification peut émettre des certificats RSA 1024 bits à partir de certificats racine distribués par le programme jusqu'à la date limite du NIST du 31 décembre 2010.
Je crois que le gouvernement américain a tenté de faire passer une loi il y a quelques années en leur donnant le droit de forcer une autorité de certification à générer un certificat valide d'une tierce partie pour l'écoute électronique et autres. Je n'ai pas pu trouver de preuve de cela, donc je me souviens peut-être de quelque chose dans le sens des discussions de DefCon mentionnées par Rory.
Supposons qu'un mauvais gouvernement veuille voir le trafic SSL des machines. Dans quelle mesure est-il possible que les autorités de certification par défaut soient contraintes de délivrer un nouveau certificat?
Le prédicat et la question ne sont pas liés. Peu importe la facilité ou la fréquence avec laquelle une autorité de certification peut être contrainte à émettre un nouveau certificat - l'écouteur potentiel ne pourrait pas voir vos données à moins qu'il n'ait la clé privée du certificat que vous avez déjà installé. IIRC (mais je recommanderais de vérifier cela) la CSR n'inclut pas la clé privée - donc l'AC ne peut pas l'obtenir de cette façon. Ils ne peuvent pas changer les clés utilisées par vos machines.
Cependant, il est possible qu'une autorité de certification non autorisée émette un certificat falsifié - et il existe alors un potentiel d'attaque MITM sur votre site. Des problèmes récents avec le format MD5 et Etisalat suggèrent que ce n'est pas impossible.
Essayer de se concentrer sur la deuxième question.
Le problème de "Quels certificats racine de confiance par défaut dois-je supprimer?" dépend essentiellement de qui vous traitez.
Vous devrez "uniquement" faire confiance à toutes les autorités de certification qui signent l'un des sites Web auxquels vous vous connectez.
Pour un utilisateur de type grand-mère qui visite toujours les mêmes quelques sites, une poignée d'autorités de certification suffira probablement, tandis que la liste ne s'allongera pas si rapidement * pour un gros internaute.
Pourquoi pas si vite ? Contre-intuitivement, certaines autorités de certification sont beaucoup utilisées (y compris les trop grosses pour échouer) tandis que d'autres ne sont que rarement utilisées sur Internet, comme certaines presque géographiques.
L'outil SSLCop de securitybydefault peut aider à bloquer les pays dont vous vous méfiez/avez peu de chances d'avoir besoin (par exemple, vous ne vous attendez pas à accéder à un site Web du gouvernement Brobdingnag, qui se trouve être le principal utilisateur de cette autorité de certification): http://www.security-projects.com/?SSLCop
Cependant, si vous ne faites pas confiance à trop d'autorités de certification, vous ne pourrez pas obtenir d'ancrage de confiance pour les sites Web dont vos utilisateurs ont besoin (et ils y accéderont de toute façon, malgré l'avertissement de sécurité), ce qui est tout aussi mauvais.
Démonstration de la création d'une autorité de certification non autorisée en utilisant les faiblesses de MD5:
Le 12 juin 2012, Microsoft a publié un nouveau programme de mise à jour qui désactivera les certificats racine non approuvés et tout autre certificat signalé à Microsoft comme non fiable.
La mise à jour est disponible ici, et je ne sais pas si cette mise à jour a déjà été distribuée via les mises à jour Windows, ou s'il s'agit d'une mise à jour hors bande.