Existe-t-il un moyen de s'assurer que mon gouvernement n'échange pas les certificats SSL?
Je me demandais récemment s'il existe un moyen de s'assurer que mon gouvernement n'échange pas les certificats SSL afin d'intercepter le trafic.
Je sais que presque tous les navigateurs se plaignent en cas de certificat auto-signé. Mais qu'est-ce qui empêche un gouvernement d'émettre son propre trousseau?
On peut imaginer compromettre les référentiels contenant des packages avec des certificats CA puis émettre leur propre certificat afin de déchiffrer le trafic. Tout le trafic passe par un opérateur de niveau 1 fidèle au gouvernement, qui dispose également de droits de monopole sur l'accès à Internet.
Si ce n'est pas un cas possible, quel mécanisme les empêche de le faire?
Si votre adversaire est un puissant acteur de la menace d'un État-nation, le web PKI ne vous protégera pas.
Rien ne les empêche de délivrer leur propre certificat. En fait, de nombreux gouvernements gèrent leurs propres autorités de certification, telles que S FPKI et affiliés . Voir une liste des autorités de certification actuellement de confiance par Firefox:
- Gouvernement de la France
- Gouvernement de Hong Kong (SAR), Hongkong Post
- Gouvernement du Japon, Ministère des affaires intérieures et des communications
- Gouvernement espagnol, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Gouvernement espagnol (CAV), Izenpe S.A.
- Gouvernement des Pays-Bas, PKIoverheid
- Gouvernement de Taïwan, Government Root Certification Authority (GRCA)
- Gouvernement turc, Kamu Sertifikasyon Merkezi (Kamu SM)
Bien que Firefox refuse actuellement de faire confiance au FPKI américain, il fait toujours confiance à de nombreuses autres autorités gouvernementales, et un acteur sophistiqué de l'État-nation a absolument accès à certaines autorités de certification commerciales existantes. Chrome, Internet Explorer et Edge utilisent le magasin d'approbation système qui, pour Windows, inclut de nombreuses autorités de certification gouvernementales, y compris le FPKI américain. N'importe lequel de ces éléments pourrait être utilisé pour signer un certificat valide pour n'importe quel site Web et votre navigateur se ferait un plaisir de leur faire confiance sans sourciller.
Bien que la nouvelle norme expérimentale pour Transparence des certificats (CT) aide à réduire l'impact des certificats émis par erreur, elle ne protège pas contre un attaquant dédié qui contrôle une autorité de certification malveillante. Une fois qu'il a été adopté de plus en plus, il peut cependant faciliter la détection des autorités de certification malveillantes ou qui se comportent mal après une courte période de temps, mais il n'empêchera pas l'attaque immédiatement lors de son exécution.
Certains navigateurs utilisent épinglage de certificat où les domaines importants et de haut niveau sont validés par rapport à une liste codée en dur des autorités de certification autorisées. La signature d'un certificat frauduleux pour ces domaines nécessiterait de compromettre l'autorité de certification qu'ils utilisent actuellement. Malheureusement, cela ne s'applique qu'à une petite poignée de domaines et ne pas protège le Web dans son ensemble.
Une solution partielle serait de refuser de faire confiance à un domaine sans le TLD .gov dont le certificat a été émis par une autorité de certification gouvernementale, qui pourrait être implémenté côté client, mais cela aurait probablement peu d'impact dans le monde réel. Un gouvernement accusateur ne signera pas un site Web malveillant avec une autorité de certification publique, car cela leur attribuerait immédiatement l'attaque. Au contraire, ils exploiteraient des relations secrètes avec des autorités de certification existantes pour les tromper ou les forcer à signer le certificat. CT, comme mentionné dans le paragraphe précédent, le détecterait et l'attaque serait rapidement remarquée, mais cela ne l'empêche pas.
Même si vous disposez des certificats CA d'origine, le navigateur/système d'exploitation peut être modifié pour ne pas vérifier correctement les certificats. Ou le navigateur/le système d'exploitation peut être détourné afin que les données simples puissent être extraites directement de l'application avant le cryptage ou après le décryptage. Et ces modifications ou changements critiques dans le comportement peuvent également être causés par le matériel que vous utilisez.
Cela signifie essentiellement que vous demandez comment vous assurer que le système que vous utilisez (matériel, système d'exploitation, logiciel, configuration ...) n'a que les fonctionnalités que vous attendez, c'est-à-dire qu'il n'a que les fonctionnalités prévues par le fournisseur et les développeurs (pas de portes dérobées ou similaires ajouté plus tard) et que cette fonctionnalité n'inclut rien qui puisse être utilisé contre vous (pas de portes dérobées par le vendeur/développeur mais aussi pas de bogues critiques qui pourraient être utilisés comme porte dérobée).
Malheureusement, il n'y a aucun mécanisme pour s'assurer que votre système se comporte comme ça. En fin de compte, cela se résume à quel point vous pouvez faire confiance à la chaîne de livraison à la fois en termes de portes dérobées explicites mais également en ce qui concerne les bogues (portes dérobées par inadvertance). La chaîne de livraison signifie dans quelle mesure vous pouvez faire confiance aux sources d'où vous avez obtenu votre matériel et vos logiciels (fournisseurs, téléchargements sur Internet ...) et également comment le matériel et les logiciels ont été protégés contre toute altération pendant le transport depuis la source. Et ces sources utilisent généralement des composants tiers, ce qui signifie que la question de savoir à quel point la chaîne de livraison peut être fiable doit être étendue.
Il existe plusieurs façons de faire confiance à la chaîne de livraison, mais une confiance totale n'est pas possible. Une façon consiste à connaître votre chaîne de livraison en premier lieu et à la garder suffisamment petite pour que vous puissiez réellement la vérifier. Cela implique également d'avoir des systèmes moins complexes car ils permettent une chaîne de livraison plus petite et plus facile à auditer. Bien que cela puisse être possible pour certains gouvernements ou de très grandes entreprises qui doivent craindre des attaques ciblées, cela est pratiquement impossible pour les utilisateurs finaux normaux. Ceux-ci pourraient essayer de réduire le risque en achetant uniquement auprès de fournisseurs de confiance (à l'étranger si vous ne faites pas confiance aux fournisseurs locaux) et de minimiser ce qui est téléchargé sur Internet et de vous assurer qu'il est toujours chargé via un transport sécurisé. On peut également essayer de comparer les parties critiques (comme les certificats d'autorité de certification locale ou l'autorité de certification utilisée pour une connexion spécifique) avec d'autres.
Il existe également des mécanismes tels que le démarrage sécurisé ou l'épinglage de certificats qui aident à empêcher ou à détecter des modifications plus petites, mais peuvent être simplement contournés par un attaquant plus sophistiqué (agences gouvernementales) qui pourrait remplacer/désactiver les vérifications pertinentes s'il contrôle suffisamment la chaîne de livraison.
À la fin, un utilisateur final non averti n'a pas beaucoup de chance de faire la distinction entre un comportement système normal et anormal car il n'a pas suffisamment de détails à quoi devrait ressembler un comportement système normal en premier lieu. Mais en supposant que des attaques telles que le remplacement de certificats d'autorité de certification ou de MITM à l'aide d'une autorité de certification contrôlée par le gouvernement (et approuvée par un navigateur) ne cibleront pas uniquement ces utilisateurs peu sophistiqués, mais seront plus répandues, il est probable que certains utilisateurs plus paranoïdes et également bien informés seront affectés et détecteront le attaquer et avertir les autres.
Il est également probable que l'attaquant ne contrôlera pas suffisamment la chaîne de livraison, surtout si un accès plus ou moins gratuit à Internet est possible (c'est-à-dire principalement un accès gratuit en dehors de certaines listes noires explicites). Dans ce cas, les utilisateurs peuvent télécharger un logiciel qui a ajouté une protection - comme les épingles SSL intégrées pour les domaines critiques dans les navigateurs comme Chrome ou Firefox. D'autre part, les utilisateurs paranoïdes peuvent également être trompés dans télécharger un logiciel qui prétend protéger sa vie privée mais est à la place un cheval de Troie d'espionnage .
Oui. Vérifiez l'autorité de certification émettrice du certificat et son empreinte digitale et/ou toute la clé publique, que vous pouvez trouver en affichant les détails du certificat dans votre navigateur. Comparez-les avec les valeurs vues par une autre personne ou un autre ordinateur en dehors du domaine du contrôle du gouvernement concerné. Vous pouvez le faire avec un vps bon marché hébergé dans un autre pays en utilisant des outils de ligne de commande pour établir la connexion TLS et vider les informations du certificat. Vous pouvez également utiliser les journaux de transparence des certificats pour voir si vous obtenez un certificat différent de ce qui est présenté aux autres utilisateurs.
C'est en effet un risque et si vous allez faire quelque chose qui nécessite une "vraie" sécurité, disons quelque chose comme l'échange de codes de bombe nucléaire, c'est un vrai problème. Là encore, ce n'est pas le plus gros problème. Les acteurs traversés par l'attaque ne sont pas directement le gouvernement mais les autorités compétentes. Un gouvernement a toujours accès à la simple attaque avec un tuyau en caoutchouc, donc cela va toujours être un problème tant que les AC seront des entités publiques soumises à l'État de droit (car cela les soumettra à un ou plusieurs gouvernements et donc sensibles aux pressions ou à la violence ordinaire). Tant que cette attaque est viable, les manipulations de certificats plus raffinées sont plutôt inutiles, elles pourraient obliger les autorités de certification à les aider (et à garder le silence à ce sujet) même si elles ne seraient pas elles-mêmes des autorités de certification.
Si vous avez besoin d'un niveau de confiance plus élevé, je vous suggère de vous tourner vers différentes approches de communication impliquant également (mais pas seulement) la stéganographie et les canaux latéraux pour réduire la visibilité de vos communications et ainsi réduire la probabilité de subir des attaques.
Pour approfondir un peu plus la situation, l'idée qu'une autorité de certification peut présenter une preuve d'exactitude de ses certificats n'est pas encore très populaire, mais cela pourrait peut-être être possible dans un système de blockchain. Cela nécessiterait probablement beaucoup plus de calculs et je doute donc que ce soit viable sans certains ajustements de l'industrie actuelle. Et même alors, les gouvernements ont un très grand mot à dire sur les primitives cryptographiques qui sont sécurisées afin qu'ils puissent entacher les méthodes mêmes utilisées pour émettre des certificats, par exemple, je voudrais vous référer au programme Bullrun de la NSA et pour un exemple plus détaillé au Dual_EC_DRBG porte dérobée théorisée par Bruce Schneier et Niels Ferguson et confirmée plus tard par Edward Snowden (un argument que j'ai eu l'occasion de confronter pendant mes études avant qu'il ne soit confirmé, Dual_EC_DRBG est potentiellement sécurisé mais vous devez générer les courbes utilisées dans la primitive cryptographique vous-même, sinon vous faites essentiellement confiance à NSA pour vous donner de bonnes clés privées, notez que ce n'est pas toujours le cas avec d'autres algorithmes).