Les certificats auto-signés sont-ils réellement plus sûrs que les certificats signés par l'AC maintenant?
Les certificats auto-signés sont-ils réellement plus sûrs que les certificats signés par l'AC maintenant?
Je pose cette question car les récentes fuites concernant les programmes d'espionnage NSA et les tribunaux secrets de la FISA signifient que le gouvernement américain peut obliger les autorités de certification des États-Unis à remettre secrètement leurs certificats racine et les autorités de certification ne peuvent pas faire quoi que ce soit à cause d'un ordre de bâillon secret. Compte tenu des interceptions de communication des États-Unis dans tous les FAI et passerelles, il leur serait simple de MITM chaque connexion HTTPS entrant et de donner leur propre clé publique signée avec ce même certificat racine à la place , ce qui leur permet d'intercepter les clés privées utilisées dans la session TLS et de transmettre une copie de toutes les données à leur centre de données de l'Utah pour analyse et stockage permanent. Il semble qu'ils aient cette capacité depuis un certain temps et on ne sait pas quoi des informations ont été volées, ce qui sape fondamentalement la confiance dans l'ensemble d'Internet.
Connaissant ces informations, serait-il techniquement plus sécurisé pour une organisation privée de générer un certificat auto-signé pour un serveur, puis de copier manuellement ce certificat et de le donner à leurs utilisateurs sur un lecteur CD/USB, alors leurs utilisateurs chargeraient manuellement le certificat comme approuvé dans leurs navigateurs Web? De cette façon, si la connexion était MITM par les États-Unis, elle ne correspondrait pas à celle de leur navigateur.
Cependant, étant donné qu'il existe déjà des certificats d'autorité de certification "de confiance" préchargés à partir de Verisign, Comodo et tous dans le navigateur, car les États-Unis effectuent une attaque MITM sur la connexion ne pouvaient-ils pas simplement lancer une demande auprès du serveur réel, copier le public informations sur le certificat, puis créez un nouveau certificat sur la base de ces informations pour le domaine demandé, signez-le avec l'un des certificats de l'autorité de certification racine dont ils disposent qui sont approuvés par le navigateur, leur permettant ainsi d'intercepter les données? Personne ne se soucie vraiment de regarder ces choses pour voir si le certificat a été signé par la bonne entreprise Verisign, Comodo ou une autre. Les utilisateurs regardent simplement le cadenas. Cela ne semblerait suspect qu'à l'administrateur qui se souvenait d'avoir créé un certificat auto-signé, pas un certificat signé par Verisign ou une autre société.
Cela m'a fait réaliser que les États-Unis n'ont besoin que d'un seul certificat CA douteux préchargé et approuvé par la plupart des navigateurs pour pouvoir effectuer des attaques MITM sur n'importe quoi, ils échangent simplement le vrai certificat d'un site contre un nouveau où ils l'ont signé avec l'un des les certificats d'autorité de certification racine approuvés par le navigateur. Si tel était le cas, vous auriez besoin d'un nouveau profil de navigateur, supprimez TOUS les certificats de confiance, chargez le certificat de confiance de votre propre organisation et utilisez ce navigateur uniquement pour communiquer au sein de votre organisation. Toute tentative MITM lancerait un gros avertissement dans le navigateur.
Il y a un point subtil ici. Dans la situation envisagée, il existe une (ou plusieurs) autorité de certification non autorisée qui peut émettre de faux certificats pour attaques man-in-the-middle . La vulnérabilité ne concerne pas ici un serveur qui utilise un certificat (authentique) de cette autorité de certification non autorisée; il s'agit du client potentiellement acceptant un certificat de cette autorité de certification. Pour vous protéger (en tant que client) contre l'autorité de certification non autorisée, vous devez ne pas faire confiance à cette autorité de certification (c'est-à-dire la supprimer de votre magasin de certificats "racines de confiance"). Cela signifie simplement implique que les serveurs auxquels vous souhaitez toujours parler doivent utiliser une autre autorité de certification distincte pour leurs certificats.
Dans une entreprise, produire des certificats auto-signés et les envoyer à tous les clients est vraiment un cas particulier de maintenir votre propre PKI : l'entreprise produit un ou plusieurs racines, qui doivent être installées dans tous les clients. C'est faisable; certaines sociétés font exactement cela. Mais pour MitM comme discuté ici, rien n'est gagné jusqu'à ce que le magasin "racines de confiance" de tous les clients soit nettoyé de tous les autres CA potentiellement mauvais.
Malheureusement, vous ne pouvez pas nécessairement le faire . Si votre système d'exploitation est Windows, il existe de nombreuses signatures utilisées pour divers composants, en particulier pour les mises à jour de Microsoft. Vous faites voulez installer des correctifs de sécurité, n'est-ce pas? Vous pouvez vous en sortir en supprimant la plupart des autorités de certification racine de vos "racines de confiance", mais pas toutes, sinon de nombreuses choses se briseront dans votre système d'exploitation.
Le problème conceptuel est que certains OS (en particulier Windows) utilisent un mécanisme centralisé pour la validation des certificats, dans lequel il y a un magasin de confiance qui est jugé approprié pour tout ce qui concerne la validation des certificats sur la machine (dans les détails, il existe un magasin de confiance "machine locale", commun à tous les utilisateurs, et un magasin de confiance supplémentaire par utilisateur, mais un utilisateur ne peut pas "désactiver" le magasin de confiance de machine locale commune). Vous pouvez avoir plus de chance avec d'autres systèmes d'exploitation tels que Linux, qui n'utilisent pas traditionnellement les certificats X.509 pour leurs besoins internes, mais les clés OpenPGP, avec un système de confiance beaucoup plus décentralisé.
Le navigateur Web Firefox , cependant, utilise sa propre implémentation SSL et magasin de confiance, séparé de celui du système d'exploitation de base. De plus, Firefox prend en charge les profils , ce qui signifie qu'un utilisateur peut avoir plusieurs "personas" avec Firefox, chacun avec ses propres paramètres, y compris l'ensemble des racines de confiance. Par conséquent, une entreprise qui craint pour la confidentialité de ses données pourrait faire ce qui suit: elle pourrait demander à ses employés, lorsqu'ils traitent avec des serveurs d'entreprise, de toujours utiliser Firefox, avec un profil spécifique qui ne contient que la racine (ou l'ensemble d'auto) de l'entreprise. certificats signés) comme "racines de confiance".
Il n'est pas clair si lesdits employés le souhaiteraient, mais c'est faisable.
N'oubliez pas, cependant, qu'un attaquant puissant est puissant. Si cet attaquant peut contrôler une "autorité de certification officielle", il pourrait alors pousser une fausse mise à jour, prétendument signée par Microsoft, qui installe une porte dérobée dans chaque système. Ou ils pourraient simplement demander à Microsoft de planter eux-mêmes la porte dérobée. Dans tous les cas, vous n'avez pas beaucoup de choix: par construction, vous devez faire confiance au système d'exploitation et au matériel pour ne pas vous jouer de mauvais jeux.
Les plugins de navigateur comme Certificate Patrol pour Firefox peuvent vous avertir des changements depuis la dernière ou la première fois que vous avez visité; mais vous constaterez que de nombreuses solutions de topologie de réseau et d'équilibrage de charge légitimes se sont appuyées sur cette faille de confiance interchangeable de SSL - vous vous retrouverez donc avec une tonne d'invites et d'avertissements lors de la navigation sur Internet.
Vous avez raison de dire que les certificats auto-signés ou les autorités de certification racine privées sont plus sûrs que les autorités de certification racine publiques préapprouvées; à condition que vous ayez raison de faire confiance à la chaîne de certificats privés et à un canal sécurisé pour le recevoir. C'est-à-dire: Ne faites confiance qu'aux certificats auto-signés que vous avez raison de faire confiance. Vous devrez supprimer toutes les autres autorités de certification racine pré-approuvées.
Il existe peut-être deux instances de navigateur de marques différentes sur l'ordinateur. Un pour une communication sécurisée utilisant uniquement un petit ensemble d'autorités de certification racine approuvées; et une autre instance de navigateur Vanilla pour les communications non sécurisées.
Initialement, le chiffrement asymétrique (paires de clés publiques/privées) était censé impliquer une forme de confiance plus directe, comme la popularité des parties physiques à la signature des clés dans les années 1990. Une approche réaliste exacte n'avait pas été entièrement étoffée avant l'explosion d'Internet au milieu des années 90.
Comme ces réseaux de confiance physiques étaient considérés comme inutilisables pour le commerce électronique sur des distances nationales ou internationales - nous avons accepté la création de sociétés agissant en tant qu'AC racines "dignes de confiance" pour le reste de la communauté des affaires; probablement en mesure d'être poursuivi s'ils signaient des certificats qu'ils n'avaient pas vérifiés. Bien qu'il s'agisse d'une solution (généralement adéquate) pour citizen<->business confiance à des fins de commerce électronique; il ne fait rien pour la protection contre les entités disposant des ressources et des pouvoirs juridiques nécessaires pour mettre sur écoute et contraindre les autorités de certification commerciale.
Pour paraphraser: Le meilleur mensonge que la NSA * ait jamais dit était que leur espionnage n'existe pas ou ne fonctionne pas.
La conservation des données porte cela à un tout autre niveau.
Personnellement, depuis la lecture La lumière des autres jours , j'ai absorbé de façon subliminale l'idée que rien n'est vraiment privé. Cela dépend simplement de l’intérêt que vous portez aux pouvoirs en place, de ce qui est à leur disposition et de l’existence d’une démocratie saine pour les contrôler.
* ou [insérer ici l'agence d'espionnage préférée]
Tout le monde ici a tout à fait raison, mais voici une réponse directe simple à votre question.
Si vous pouvez communiquer avec le propriétaire du serveur hors bande la première fois que vous acceptez un certificat auto-signé et vérifiez qu'il s'agit bien de son certificat et que vous ne reconnaissez qu'un seul certificat pour les futures connexions à son serveur, alors en théorie, un tel la configuration pourrait être plus sécurisée qu'un certificat traditionnel signé par une autorité de certification. Le scénario de transport de clé USB fonctionnerait ici comme une communication hors bande, tant que vous pouvez être assuré que la clé USB n'a pas été compromise d'une manière ou d'une autre.
Dans un tel cas, vous pouvez le faire, que leur certificat soit signé par une autorité de certification ou auto-signé, et si ce certificat est toujours "épinglé" par votre navigateur (ou dans votre esprit; vous devriez donc vérifier qu'il s'agit de la même signature pour chacun et chaque visite), alors vous pouvez être relativement sûr qu'aucun MitM ne se passe. Cela implique d'avoir à parler directement et à faire confiance à chaque opérateur de serveur au préalable, et cela n'est souvent pas possible.
Ce scénario nécessiterait également un canal de révocation hors bande également, dans le cas où une entité hostile s'introduirait dans son serveur et volerait sa clé privée. Et si vous dites "eh bien, que se passe-t-il si l'opérateur du serveur n'est pas au courant du compromis de la clé privée?" alors peu de choses peuvent être faites; c'est un problème que SSL/TLS ne peut pas empêcher en général.
Il est plus sûr d'utiliser un certificat épinglé que de se fier uniquement à la signature CA. Cela dépend du fait que le certificat soit auto-signé ou signé par une autorité de certification.
Cependant, vous devez assurer la distribution du pinnng :-)
Dans le cas où vous distribuez un "navigateur sécurisé" sur CD, vous pouvez installer un raccourci avec une ligne de commande comme le "Twitter Like A Boss" de http://scarybeastsecurity.blogspot.com.es/2011 /04/fiddling-with-chromiums-new-certificate.html
(attention: current Chrome ne prennent pas en charge la propriété public_key_hashes dans HSTS, qui est utilisée dans cette ligne de commande pour épingler le certificat)
Avoir uniquement un certificat auto-signé ne le rend pas plus sûr. Une fois qu'elle est compromise, vous devez informer personnellement tous vos clients que la connexion n'est plus sécurisée et qu'ils ne doivent plus y faire confiance, déployer le nouveau certificat et vous devez croiser les doigts pour que tous vos clients soient informés à temps.
Si vous voulez suivre cette voie, vous devez créer votre propre autorité de certification avec votre propre certificat racine privé (généré sur une machine qui ne s'est jamais connectée à Internet). Vous devez conserver la clé sur une clé USB uniquement et la placer dans un coffre-fort et la retirer uniquement si vous avez besoin d'émettre un nouveau certificat (demande) (encore une fois, ne le faites que sur un ordinateur qui n'a jamais vu le World Wide Web) . Avoir une autorité de certification vous donne la possibilité de créer de nouveaux certificats selon vos besoins. Configurez ensuite un serveur OCSP pour que vos clients puissent vérifier à la demande (s'il s'agit de votre logiciel client, vous devez appliquer la vérification OCSP avant toute connexion) si des certificats ont été révoqués.
Lorsque tout est configuré et fonctionne, vous devez espérer que rien ne va mal (vos serveurs sont piratés). Mais c'est beaucoup de travail, et le garder en sécurité n'est probablement pas bon marché.