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:

• ImperialViolet - DNSSEC et TLS

• Network Notary - Perspectives: Amélioration de l'authentification d'hôte de style SSH avec la détection de réseaux multi-chemins

• Blog de sécurité en ligne Google: Amélioration de la sécurité des certificats SSL

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.

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.

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.

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 ....

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.

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.

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é.

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.

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

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:

   • WebTrust pour les autorités de certification v1.0 ou version ultérieure, réalisés par un auditeur WebTrust pour les autorités de certification agréé,

   • ETSI TS 101456 v1.2.1 ou version ultérieure,

   • ETSI TS 102042 V1.1.1 ou version ultérieure, ou

   • ISO 21188: 2006, «Infrastructure à clé publique pour les services financiers - Pratiques et cadre politique», complété soit par un auditeur agréé WebTrust pour les CA ou une autorité d'audit fonctionnant conformément aux lois et politiques applicables aux évaluateurs dans la même juridiction que l'AC.

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.

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

• Recherche originale
• Couverture médiatique

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.

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