Question:
Dans quelle mesure est-il possible pour une autorité de certification d'être piratée? Quels certificats racine de confiance par défaut dois-je supprimer?
goodguys_activate
2011-02-24 01:54:23 UTC
view on stackexchange narkive permalink

Cette question a été révisée & considérablement clarifiée depuis la version originale.

Si nous examinons chaque certificat de confiance dans mon magasin Trusted Root, dans quelle mesure devrais-je leur faire confiance?

Quels facteurs faut-il prendre en compte lorsque j'évalue la confiance de chaque autorité de certification racine pour une éventuelle suppression de mon magasin local?

Plus d'informations:
Si une autorité de certification émet un certificat à une partie incorrectement validée, alors toutes les machines qui font confiance à cette autorité sont vulnérables aux attaques MITM. En conséquence, 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'autorité de certification est soumise à une intervention humaine et offre des opportunités de émettre un certificat à la mauvaise partie. Cela peut être dû à une erreur d'opérateur de l'autorité de certification, à des demandes gouvernementales ou peut-être à la contrainte (pot-de-vin) d'un opérateur de l'autorité de certification.

J'aimerais en savoir plus sur les autorités de certification par défaut les plus susceptibles de délivrer 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 exige une exception au processus de vérification de l'autorité de certification. Ce gouvernement exige é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.

Confiance par défaut Windows Azure

Windows Azure prend en charge 275 autorités de certification comme indiqué dans le lien suivant. En fonction de l'utilisation de l'AC particulière, certaines de ces CA 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é de certification par défaut de VMWare si vous les rencontrez.

Mozilla↑

Une liste de tous les certificats et déclarations d'audit est disponible.

Apple iOS

Liste de tous les certificats racine iPhone mentionnés dans ce # WWDC2017. vidéo

Je pense que vous devez nettoyer votre terminologie. Les «certificats» sont des informations accessibles au public. Je pense que vous voulez dire «paire de clés» et que vous faites beaucoup de présomptions ici que toutes les paires de clés SSL sont générées de la même manière, et que toute autorité de certification n'utilise qu'une seule façon d'émettre des clés et des certificats. De plus, je pense que vous voulez probablement dire "Trusted Cert Store" et non "Trusted Root Store" parce que vous pourriez parler d'un CA intermédiaire faible signé par une racine de confiance décente ...
@bethlakshmi - J'avais l'impression que la clé privée n'a jamais été envoyée à l'autorité de certification en amont, et je n'ai pas dit keypair pour cette raison. Est-ce incorrect?
Non, ce n'est pas le cas ... mais les autorités de certification sont chargées de délivrer des certificats, alors j'essaie de comprendre ce que vous entendez par «contraint»? De nombreuses autorités de certification peuvent être amenées à délivrer un certificat en leur donnant un tarif forfaitaire ... ce qui n'est guère une "coercition". J'ai supposé que vous vouliez que l'autorité de certification renonce à sa clé privée? Si vous voulez dire "forcé à émettre un certificat * sans faire l'authentification appropriée requise par sa politique de sécurité *", alors ce serait également une clarification utile.
@bethlakshmi - J'ai apporté plusieurs clarifications. J'apprécierais votre avis ...
Clarifier votre modèle de menace serait très utile, comme indiqué dans la FAQ. Je m'attends à ce que de nombreux CA soient vulnérables à une attaque à grande échelle d'un grand gouvernement averti, que ce soit par la coercition ou l'ingénierie sociale ou en exploitant des vulnérabilités. Tous ces éléments ont déjà été démontrés dans la nature. Si vous n'êtes qu'un petit poisson, vous devez probablement vous inquiéter de quelques CA qui semblent être étroitement associées aux gouvernements qui aiment fouiner. Si vous pouvez le limiter à 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.
Connexes: l'autorité de certification de DigiNotar a été piratée [autorisant les attaques MITM] (http://slashdot.org/story/11/08/30/1431211/Diginotar-Responds-To-Rogue-Certificate-Problem)
Un rapport indépendant de Fox-IT sur le piratage DigiNotar a été rendu public, voir http://www.scribd.com/doc/64011372/Operation-Black-Tulip-v1-0
également http://features.techworld.com/security/3408741/year-after-diginotar-security-breach-fox-it-details-extent-of-compromise/
Ma politique: supprimer tous les certificats hébergés par des pays aux gouvernements oppressifs.
Douze réponses:
#1
+66
nealmcb
2011-02-24 08:32:33 UTC
view on stackexchange narkive permalink

Mise à jour 5 Le problème racine (heh) avec le modèle CA est qu'en pratique, toute autorité de certification peut émettre des certificats pour n'importe quel domaine, vous êtes donc vulnérable au lien le plus faible. Quant à savoir à qui vous pouvez faire confiance, je doute que la liste soit très longue, car les enjeux sont élevés et la sécurité est difficile. Je recommande le post de Christopher Soghoian sur le sujet, qui clarifie les différentes approches utilisées par les gouvernements du monde entier pour accéder aux données des utilisateurs privés - que ce soit en les exigeant directement des entreprises qui exploitent des services cloud, via l'écoute électronique, ou de plus en plus maintenant via la coercition des CA ou hacks: légère paranoïa: les forces qui ont conduit au hack DigiNotar.

Ici, je donne quelques détails, et je termine par des liens vers des correctifs potentiels.

En 2009, Etisalat (détenue à 60% par le gouvernement des Émirats arabes unis), a déployé une apparence anodine Patch BlackBerry qui a inséré des logiciels espions dans les appareils RIM, permettant la surveillance des e-mails, il peut donc difficilement être considéré comme digne de confiance. Mais il fait partie de nombreuses listes d'autorités de certification 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'attaque réussie, prétendument par un Iranien nommé ComodoHacker, contre Comodo: Rogue SSL certificats ("case comodogate") - F-Secure Weblog. F-Secure note que Mozilla inclut des certificats émis par des CA en Chine, Israël, Bermudes, Afrique du Sud, Estonie, Roumanie, Slovaquie, Espagne, Norvège, Colombie, France, Taiwan, 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 de grande confiance, 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 piratages 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 Mozilla Security Blog.
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 révèlent une attaque réussie de l'autorité de certification, peut-être de l'Iran | Liberté de bricoler

Mise à jour 3 : une autre attaque réussie apparemment aussi par ComodoHacker était contre le CA DigiNotar. Leur site Web a été compromis à partir de 2009, mais cela n'a été remarqué qu'après que DigiNotar ait é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. Pour en savoir plus, consultez DigiNotar Hack met en évidence les échecs critiques de notre modèle de sécurité Web SSL | Liberté de bricoler.

Je suppose que la gamme de vulnérabilité des différentes autorités de certification varie assez largement, tout comme leur utilité. Je vous suggère donc de recentrer votre stratégie. Lorsque vous pouvez le limiter à 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 pour 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 y a un excellent article sur la réparation de notre dangereuse infrastructure de l'autorité de certification chez Freedom to Tinker: Construire une meilleure infrastructure CA

Il parle de ces innovations:

Mise à jour 4 Un de nos services informatiques Les articles du blog sur la sécurité en août 2011 couvrent également les arguments en faveur du passage à DNSSEC: Un examen basé sur les risques pour résoudre le problème de l'autorité de certification «Stack Exchange Security Blog

Update 6 Plusieurs autorités de certification ont été prises en violation des 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 des "certificats mal émis", via le contrôleur indien des autorités de certification (Inde CCA) en 2014: Blog de sécurité en ligne Google: Maintenir la sécurité des certificats numériques

Voir également la question sur Transparence des certificats qui semble être une approche utile pour découvrir plus tôt les mauvais certificats et les violations de règles.

Grands liens; Je vais l'utiliser à coup sûr +1
DNSSEC n'est pas une panacée
@nealmcb: L'article dit que le gouvernement iranien a volé le certificat d'une autorité de certification. Cela signifie que le gouv. a volé la clé privée du droit CA? Je ne comprends pas comment vous pouvez voler la clé privée
@Ashwin De quels articles parlez-vous? Notez également que si certaines clés privées sont bien protégées par du matériel sophistiqué, d'autres ne sont que des bits sur un ordinateur à usage général et peuvent être plus facilement volées. De plus, il est souvent possible d'obtenir de nouveaux certificats sans avoir la clé privée principale, par ex. en subvertissant un registraire, ou en obtenant le contrôle d'un certificat CA délégué, comme expliqué dans d'autres articles de référence ici.
Un autre abus s'est produit plus tôt ce mois-ci, dans ce cas du National Informatics Center (NIC) de l'Inde: http://googleonlinesecurity.blogspot.com.es/2014/07/maintaining-digital-certificate-security.html
Et puis il y a les certificats racine insérés par des fabricants comme Lenovo, comme le [fou de Superfish] (http://security.stackexchange.com/a/82040/453) qui est livré avec sa propre autorité de certification non sécurisée, y compris la clé privée . Débarrassez-vous de celui-là aussi!
#2
+41
D.W.
2011-03-18 21:42:01 UTC
view on stackexchange narkive permalink

Comme Matt Blaze l'a écrit un jour, les CA vous protègent de toute personne à qui ils ne veulent pas prendre de l'argent. Cela devrait vous dire quelque chose sur les incitations de l'autorité de certification et sur certains risques potentiels dans l'accord.

C'est si succinctement et si éloquemment formulé que j'ai dû accepter cette réponse. Je serais toujours intéressé par les moyens d'évaluer le risque au sein de chaque racine de confiance.
@makerofthings Mais rappelez-vous - vous êtes l'endroit où la confiance commence - le chemin est finalement circulaire. Ainsi, seul vous, en gardant à l'esprit vos actifs et vos menaces, pouvez en fin de compte évaluer si vous êtes inquiet, en fonction de ce que vous savez sur chaque autorité de certification, si elle est susceptible de vous vendre * en aval.
#3
+18
Rory McCune
2011-02-24 03:32:14 UTC
view on stackexchange narkive permalink

Je crains que la réponse courte à cette question soit qu'il soit impossible de le savoir, pour autant que je sache. 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 la probabilité qu'elles soient «dignes de confiance» en ce qui concerne la distribution de certificats à des organisations gouvernementales ou autres.

Si une autorité de certification est connue comme non fiables, ils seraient probablement supprimés des listes d'installation par défaut des navigateurs, (par @xce ci-dessous, Diginotar est un bon exemple ici et Digicert également)

En plus de l'organisation fournissant des certificats volontairement, il y a le risque que ils peuvent fournir des certificats sans effectuer de contrôles de sécurité appropriés sur le demandeur. Chez Defcon il y a quelques années, il y a eu plusieurs présentations sur le thème de la possibilité d'obtenir des certificats sans autorisation.

Si c'est une préoccupation importante, la seule façon de procéder serait de créer une liste blanche des autorités de certification que vous avez examinées et que vous êtes à l'aise avec la sécurité fournie. De toute évidence, 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.

Connaissez-vous une méthodologie pour examiner un CA?
Eh bien, la fiabilité de base pourrait être établie par un audit de style de sécurité de l'information standard (avec les mises en garde habituelles sur l'efficacité de choses comme ISO27XXX, etc.). La probabilité de transmettre des données aux organisations gouvernementales serait difficile. Je suppose que vous devez établir des protections réglementaires et juridiques pour la vie privée dans un pays donné, puis peser cela avec les incitations probables pour une organisation gouvernementale à vouloir accéder à l'information. En fin de compte, si vous êtes préoccupé par les interférences au niveau gouvernemental, je serais enclin à configurer votre CA et à ne faire confiance à aucun public :)
DigiNotar en est un exemple.
#4
+11
AviD
2011-02-28 01:26:20 UTC
view on stackexchange narkive permalink

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 avait incident assez bien médiatisé de phishing SSL - un faux site Web bancaire a reçu un certificat SSL légitime (de GeoTrust, je crois), pour une faute d'orthographe du site d'une banque régionale. (Mise à jour: ce lien historique a été trouvé - l'adresse correspond au 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 donc possible d'obtenir un certificat sans recourir à la "coercition".
  • La récente nouvelle Stuxnet 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 «de confiance», ils ont pu être mal utilisés pour implanter le malware.

Ensuite, bien sûr, il y a les scénarios logiciels dans lesquels l'AC n'est même pas appelée à être utilisée - par exemple avec des clients lourds qui appellent des services Web, qui ne prennent pas la peine de valider le certificat du serveur ....

Ce que je veux dire, c'est que si vous vous inquiétez de MITM sur SSL, le plus souvent, ce n'est pas le coercition 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 signifie pas que je devez avoir confiance que vous savez qui est quelqu'un d’autre .

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 qui communique avec un serveur (ou un ensemble de serveurs) spécifique , supprimez définitivement TOUS les certificats racine, sauf une liste blanche de ceux dont vous avez besoin.
Et si vous utilisez votre propre autorité de certification interne, c'est encore mieux ....

Bonne réponse, mais peut-être à une autre question. Bien sûr, il est toujours tentant de se demander s'il y avait des questions non posées ... Peut-être devrions-nous annoter un wiki pour la balise ssl avec les différentes questions que nous pensons toujours que les gens devraient poser ...
@nealmcb, Je suis d'accord - mais comme vous aimez le dire, "quel est votre modèle de menace?" Je voulais souligner qu'il posait la mauvaise question, pour résoudre son «problème» déclaré.
Ouais - je voudrais également voir plus de contexte dans la question pour savoir quel problème l'a provoquée. Mais c'est une question claire avec des réponses claires telles quelles. Cela mérite juste d'être dans un réseau d'autres questions plus utiles sur d'autres aspects de ssl, que nous tissons lentement sur ce site :)
#5
+9
Sander Temme
2011-08-31 11:30:09 UTC
view on stackexchange narkive permalink

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 des longueurs auxquelles elle va pour vérifier la validité de l'entité demandant des certificats. Recherchez les déclarations selon lesquelles ils protègent leurs clés de signature de l'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 des certificats, etc. Ces méthodes de protection rendent la tâche beaucoup plus difficile et plus coûteuse pour un tiers non autorisé de voler les clés de signature.

L'énorme liste d'autorités de certification de confiance (mon trousseau de racines système Mac en a 175) est là pour votre commodité, afin de 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 entendu, exclure chaque CA de cette liste à moins que vous n'ayez personnellement audité leurs pratiques. Pour un système fermé, où vous contrôlez tous les terminaux et vous disposez d'un nombre limité de parties de confiance, c'est faisable. Le système de contrôle de version de 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 de demander à une partie de confiance hors bande (la société qui fournit votre système d'exploitation ou votre navigateur, quoi que vous en pensiez) de fournir une liste de certificats qui vous permettent de vous connecter à pratiquement n'importe quel serveur SSL dans le monde.

Avez-vous vraiment besoin de tous ces certificats dans votre liste de confiance? Probablement pas. Mais le fournisseur de votre système d'exploitation / navigateur ne peut pas prévoir (et ne devrait pas contrôler) avec qui vous voulez faire affaire, donc ils les incluent tous. Le problème avec la longue liste est que vous avez des AC de tous les plumes, 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 constaté des cas d'informations d'identification de connexion de revendeur compromises, et même des clés de l'autorité de certification compromises. Certaines autorités de certification 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 CA est traité exactement de la même manière par votre navigateur.

Une ligne de défense contre les certificats non fiables 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 préoccupant. Je ne sais pas comment les navigateurs actuels traitent cette affaire et je suis trop paresseux pour le savoir.

#6
+4
Steve Dispensa
2011-09-04 21:56:07 UTC
view on stackexchange narkive permalink

Ce genre de discussion me rappelle toujours ce bogue de Mozilla demandant l'inclusion d'une nouvelle autorité de certification. Assez hilarant, mais assez perspicace.

#7
+3
Steve
2011-02-24 04:45:33 UTC
view on stackexchange narkive permalink

Je pense que le gouvernement américain a tenté de faire adopter une loi il y a quelques années, lui donnant le droit de forcer une autorité de certification à générer un certificat valide d'un tiers pour l'écoute électronique et autres. Je n'ai pas pu trouver de preuves de cela, alors je me souviens peut-être de quelque chose du genre des discussions sur la DefCon dont Rory a parlé.

#8
+3
symcbean
2011-02-24 19:57:12 UTC
view on stackexchange narkive permalink

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 d'émettre un nouveau certificat?

Le prédicat et la question ne sont pas liés. Peu importe la facilité ou la fréquence à laquelle une autorité de certification peut être contrainte d'émettre un nouveau certificat - le prétendu espion ne pourrait pas voir vos données à moins qu'il ne dispose de la clé privée du certificat que vous avez déjà installé. IIRC (mais je recommanderais de vérifier cela) le 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 que vos machines utilisent.

Cependant, il est possible qu'une autorité de certification non autorisée émette un certificat falsifié - et le potentiel existe alors pour une attaque MITM sur votre site. Des problèmes récents avec le format MD5 et Etisalat suggèrent que ce n'est pas impossible.

Vous n'avez pas besoin d'un certificat falsifié, mais simplement d'un certificat de confiance signé par l'autorité de certification contrainte pour effectuer une attaque MITM. Les pare-feu Fortinet facilitent cette tâche car ils peuvent être configurés pour effectuer des attaques MITM. La seule raison pour laquelle MITM a échoué sur moi au travail était que mon ordinateur n'avait pas le certificat Fortinet installé et de confiance, donc j'ai reçu un avertissement lors du lancement de Mac Mail (Gmail avait un certificat invalide).
#9
+3
goodguys_activate
2012-06-02 18:21:31 UTC
view on stackexchange narkive permalink

Lors de la recherche du 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

error- you're deleting a system cert!!

Ceci est 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) des certificats intermédiaires, car ils n'existent que " uniquement pour raisons héritées ".

Lorsque vous évaluez la suppression de tous les certificats restants, considérez que le programme de certificat racine Microsoft exige que l'autorité de certification passe l'une de ces normes d'audit:

  • ETSI 102042
  • ETSI 101456
  • 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 les certificats d'un navigateur non MSFT (IE), vous pouvez consulter ces directives de qualité de CA.

Restrictions

Le programme dispose également d'audits supplémentaires qui s'appliquent à l'utilisation de la clé. L'utilisation de la clé est limitée aux éléments suivants:

  • Authentification du serveur (SSL) = 1.3.6.1.5.5.7.3.1

  • Authentification du 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 de 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

  • Cryptage du système de fichiers EKU = 1.3.6.1. 4.1.311.10.3.4

  • IPSec (Tunnel, Utilisateur) 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:

  • Connexion 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 suivant de la base de connaissances 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 de récupération de clé Enterprise CA.

  • Récupération de fichier Cette EKU est obsolète et est ignorée par le système de fichiers de chiffrement Windows (EFS).

  • Toutes les politiques d'application Nous ne pouvons pas accorder «toutes les utilisations» car cela admet nécessairement les EKU d'entreprise uniquement et d'autres EKU inacceptables.

  • Courriel du service d'annuaire Scénario d'entreprise de réplication

  • Agent de demande de certificat

  • Scénario d'autorité de certification d'entreprise

  • Scénario de l'autorité de certification d'entreprise de l'agent de récupération de clé

  • Certificat de chiffrement de l'autorité de certification

  • Scénario de l'autorité de certification d'entreprise

Critères d'acceptation

De plus, les critères suivants doivent être remplis avant d'ajouter une autorité de certification générale ou gouvernementale à la racine:

  1. L'AC doit fournir les informations demandées ci-dessous (voir St ep 1. Contactez Microsoft) et recevez une approbation préliminaire pour l'adhésion au programme.

  2. L'AC doit fournir un certificat de test émis à partir du certificat racine de l'autorité de certification pour les tests fins. En option, une autorité de certification peut fournir à Microsoft une URL d'un serveur accessible au public où les certificats émis à partir de leur certificat racine peuvent être vérifiés. (Consultez la FAQ pour plus de détails)

  3. L'AC doit remplir un contrat Microsoft CA. L'accord ne sera fourni qu'après avoir terminé l'étape 1 du processus de candidature et reçu l'approbation préliminaire de votre candidature.

  4. Les certificats racine doivent être conformes à la section Exigences techniques ci-dessous. En particulier, nous exigeons une taille minimale de clé de chiffrement du module RSA 2048 bits pour toute racine et toutes les autorités de certification émettrices. Microsoft n'acceptera plus les certificats racine avec un 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.

  5. Certificats émis à partir d'un certificat racine doit prendre en charge l'extension de point de distribution CRL. Le point de distribution CRL doit pointer vers un emplacement accessible au public.

  6. L'autorité de certification doit avoir une politique de révocation documentée et l'autorité de certification doit être en mesure de révoquer tout certificat qu'elle émet.

  7. 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 d'usages de clé étendus (EKU). Toutes les utilisations de certificat que nous activons doivent être vérifiées périodiquement. Le rapport d'audit doit documenter la portée complète de la hiérarchie PKI, y compris toute sous-autorité de certification qui émet un type spécifique de certificat couvert par un audit. Les audits éligibles incluent:

Il s'agit des audits actuellement acceptés pour les CA non gouvernementales. 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 racines doivent être x.509 v3 certificats.

  • Le nom du sujet doit contenir un nom significatif de l'autorité de certification (ex. ne peut pas être «Root» ou «CA1»)

  • Extension de contraintes de base: cA = true

  • Utilisation de la clé (si présente): keyCertSign et cRLSign uniquement

  • Root Les exigences relatives aux tailles de clé sont basées sur le NIST SP 800-57:

      RSA supérieur ou égal à 2048 bits module ECC supérieur ou égal au module P256  
  • L'algorithme de hachage doit être au moins SHA1. Aucun hachage MD2, MD4 ou MD5 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 importantes.

  • Les certificats de l'autorité de certification intermédiaire sont exclus du programme de l'autorité de certification racine (voir les questions fréquemment posées pour en savoir plus informations)

  • L'AC ne délivrera pas de certificats subordonnés ou d'entité finale MD2, MD4 ou MD5 à partir de tout 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 du NIST du 31 décembre 2010, sauf dans les cas fournis par Microsoft.

  • L'AC 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.

#10
+1
Bradley Kreider
2011-02-24 21:04:50 UTC
view on stackexchange narkive permalink

Démonstration de la création d'une autorité de certification non autorisée en utilisant les faiblesses de MD5:

Veuillez inclure du contenu réel et pertinent dans les réponses - pas seulement des liens.
Point pris, mais il répond à la première question: dans quelle mesure est-ce faisable: très.
#11
+1
Ángel
2014-07-18 04:07:23 UTC
view on stackexchange narkive permalink

Vous essayez de vous 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 la personne avec qui vous traitez.

Vous n'aurez "que" besoin de 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, probablement une poignée d'autorités de certification suffira, alors que la liste ne s'allongera pas si vite * pour un gros internaute.

Pourquoi pas si vite ? Contre-intuitivement, certaines autorités de certification sont beaucoup utilisées (y compris celles qui sont trop grandes pour échouer) tandis que d'autres ne sont que rarement utilisées sur Internet, comme certaines quasi-géographiques.

L'outil SSLCop de securitybydefault peut aider à bloquer les pays dont vous vous méfiez / dont vous n'avez probablement pas besoin (par exemple, vous ne vous attendez pas à accéder à un site Web du gouvernement Brobdingnag, qui se trouve être l'utilisateur principal 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 une ancre de confiance vers 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.

#12
  0
goodguys_activate
2012-08-09 16:36:17 UTC
view on stackexchange narkive permalink

Depuis 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 suis pas certain 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.

http://support.microsoft.com/kb/2677070



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...