Faiblesses HTTPS. 2e partie

Tout système a ses propres forces et faiblesses. La première partie sur les faiblesses du HTTPS a provoqué une réaction ambiguë selon laquelle «ce ne sont pas des faiblesses, il devait en être ainsi». La première partie disait:

1. À propos de l'impossibilité de fournir une confidentialité et une confidentialité complètes aux utilisateurs (vous pouvez toujours suivre et interdire les ressources qu'une personne visite)
2. Le fait que les certificats sont transmis sur un canal ouvert et contiennent souvent plus d'informations que la ressource actuelle (par exemple, le certificat bing.com contient des informations sur 72 ressources supplémentaires, y compris virgo, test, environnement bêta)

Je continuerai de l'appeler «faiblesses» du design. Dans cet article, nous parlerons d'une autre faiblesse - la centralisation .

HTTPS est basé sur les protocoles SSL et TLS (pour simplifier, nous appellerons simplement SSL - bien que SSL et TLS fonctionnent à différents niveaux de la pile OSI). Par conséquent, en parlant de faiblesses, nous garderons à l'esprit la centralisation du protocole SSL.

Théorie

Commencez avec la théorie des protocoles de chiffrement. Le problème avec la cryptographie moderne n'est pas le cryptage lui-même, mais ce qu'il faut faire avec les clés: comment les stocker, les transférer, les créer et les détruire en toute sécurité.

La base de SSL est le chiffrement asymétrique , qui est déterminé par la présence de deux clés - si l'une est chiffrée, alors seule la seconde peut déchiffrer, et vice versa.

La fonction principale du chiffrement asymétrique est l' authentification , pas le chiffrement du tout - c'est une opération coûteuse en ressources et coûteuse pour cet algorithme. Le chiffrement rapide et efficace est la prérogative des algorithmes symétriques qui utilisent la même clé pour le chiffrement et le déchiffrement.

L'une des clés reste toujours sur un côté pour confirmer son identification, elle est dite privée . La clé publique est accessible à tous.

Imaginez qu'il y ait un village du futur dans lequel Boris et Anya vivent. À l'avenir, les clés d'une taille différente sont déjà plus strictes et les capacités du cerveau sont disproportionnées par rapport au moderne, mais l'approche, supposons, reste la même.

Boris et Anya veulent l'intimité de leur correspondance amoureuse, donc l'essentiel pour eux est un échange sécurisé d'informations.

Dans le cas le plus simple, Boris envoie un message à Anna: «Parlons». Anya génère deux paires de clés de chiffrement asymétriques - Pr1 privé et P1 public. "Allez," dit Anya, "Je suis Anya, voici ma clé publique, voici l'algorithme de chiffrement symétrique que je connais." Boris génère une clé symétrique S1, la chiffre avec la clé publique Ani P1 (S1). Maintenant, même Boris lui-même ne pourra pas décrypter S1, car seule Anya peut décrypter le message avec sa clé privée. Au final, Boris et Ani ont une clé de session symétrique pour «assurer» une transmission fiable des lettres entre elles et empêcher les parents de lire leur correspondance.



En particulier, je n'ai pas fortement réduit cette messagerie, en fait, nous avons décrit SSL Handshake avec authentification unidirectionnelle [1]. Sur une base bidirectionnelle, Boris génère sa propre paire de clés et transfère la clé publique à Anya.

Une conclusion importante que nous pouvons déjà tirer. Des trois fonctions principales du protocole SSL (authentification, cryptage, intégrité), la plus importante est l'authentification.

Tout va bien jusqu'à ce qu'un facteur apparaisse, offensé par la vie, qui est avide de lire les lettres des autres, et en plus est également intelligent. Entre Boris et Anya, la question se pose de savoir comment garantir maintenant que le facteur ne pourra pas lire leurs messages. La réponse n'est pas possible. Le facteur peut générer sa propre paire de clés, exposer à Boris sa clé «prétendument» d'Ani, organiser deux chaînes cryptées et lire les lettres calmement.



Le dilemme ne peut être résolu que par la présence d'un certain tiers qui peut garantir que la clé P1 appartient à Ana. Imaginez qu'un conseil de village apparaisse dans le village, qui tient un registre des clés publiques pour les résidents. Anya peut prendre son passeport, sa clé publique P1, y aller et demander à s'inscrire. Boris, lorsqu'il reçoit P1 d'Ani, il peut se rendre au même conseil de village et vérifier le registre. Si la clé ne correspond pas, vous pouvez commencer à pécher le facteur et le blâmer pour tout sérieux, bien qu'il puisse aller dans le déni. Mais le problème est toujours en cours de résolution.



Pas un camilpho, bien sûr, Boris se trimballait à chaque fois avec le conseil du village. Par conséquent, la même authentification peut être effectuée avec le conseil de village lui-même. Le conseil du village s'appelle désormais autorité de certification (CA) et possède sa propre paire de clés, P10 et Pr10. Quand Anya arrive avec un passeport et sa clé publique, CA émet quelque chose comme une carte qui indique que c'est Anya, elle possède la clé publique P1, quelques autres informations, jusqu'au numéro de passeport, et ajoute un autre champ pour elle signatures: prend toutes les informations de la carte, enlève le hachage, et la chiffre avec sa clé privée, et l'appelle une signature numérique. Il serait possible de se passer d'un hachage, mais la signature était alors trop grande. Et l'AC appelle maintenant cette carte un certificat.

Maintenant, pour échanger des messages d'amour avec Anya, Anya lui donne non seulement son nom et sa clé publique, mais son certificat. Boris n'aura besoin de se rendre qu'une seule fois au conseil du village et de lui demander sa clé publique. Toute information que cette clé peut décrypter sera a priori considérée comme cryptée par le conseil de village. Le facteur ne sait pas quoi faire du tout, il est couvert par un vide existentiel, il ne lui reste qu'une chose - essayer de récupérer la clé privée du conseil de village pour que la vie redevienne normale.



Mais la vie ne s'arrête pas. Boris a une autre petite amie dans un village voisin, puis une autre. Il doit ajouter les clés des autres conseils de village à ceux de confiance, commence à tenir son registre avec les clés publiques des autorités de certification. Elle gagne ensuite une échelle nationale et supranationale. Il y a tellement d'organisations qui signent des certificats qu'elles commencent à fusionner dans une hiérarchie. L'Autorité de certification racine apparaît, qui ne signe pas les certificats de simples mortels, mais signe les certificats des centres intermédiaires (Autorité de certification intermédiaire) après les avoir vérifiés. Il suffit maintenant à Boris de ne stocker que les clés publiques des certificats racine. Et d'Ani, il reçoit non seulement un de ses certificats, mais aussi des certificats de centres intermédiaires, afin de les vérifier davantage jusqu'au centre racinaire.

Champ de problème

Le système devient plus complexe et centralisé , et à partir de ce moment, le facteur a de nouveau une chance.

D'une part, Boris dispose initialement d'une petite liste d'autorités de certification racine (Windows prescrit environ 50 autorités de certification racine lors de l'installation). En revanche, il lui est difficile de suivre à chaque fois toute la chaîne des centres de certification. Très probablement, il ne vérifiera plus que le certificat d'Ani de son propre village indique pour une raison quelconque le centre de certification d'un autre pays. Il fait confiance à sa liste de centres racinaires à 99,9%. Un facteur peut emprunter le chemin le plus brutal, et en quelque sorte (ingénierie sociale, piratage avec pénétration) enregistrer sa fausse autorité de certification racine dans le registre de Boris.



PS. Cette méthode d'ajout d'un faux certificat de centre racine est activement utilisée par les pentesters (comme moi) et les attaquants. Pour effectuer des tests de pénétration et utiliser cette approche, mon outil préféré est ZapProxy (gratuit et open source), qui générera un certificat de centre racine (il devra être installé manuellement), puis à la volée remplacer ce certificat par un certificat "similaire". Cela vous permet non seulement de visualiser le trafic, mais aussi de l'arrêter, de le modifier et de l'envoyer plus loin. Par conséquent, si la validation sur votre système n'est pas dupliquée sur le serveur, vous avez certainement des problèmes.

PPS Le deuxième problème qui a été soulevé dans cette affaire concerne Ani et l'indication d'un centre incompréhensible dans son certificat. Anya a payé l'argent et aimerait que Boris la reconnaisse quand même. Ce problème est résolu à l'aide de SSL Pinning [3], lorsque l'application ne peut être approuvée que dans un certain certificat et certaines autorités de certification. Ceci est particulièrement utile pour les applications à haut risque. Avec les navigateurs, c'est plus compliqué, pour les applications mobiles qui fonctionnent avec un ou deux services, c'est plus simple. Par souci d'expérience, j'ai mis un faux certificat sur mon Android, indiqué que le trafic devait passer par ZapProxy, qui se prolonge sur le réseau de ma machine, et regardé combien d'applications utilisent ce mécanisme. Presque personne, j'ai pu regarder et jouer avec la substitution du trafic avec presque toutes les applications populaires.

Revenons donc à notre facteur. Le gouvernement ne peut qu'apprécier son zèle et lui donne le statut d'agent secret aux pouvoirs supérieurs. Bien que les clés privées des autorités de certification racine soient stockées sous sept verrous, des disques auto-gravables, une protection à plusieurs niveaux - même l'autorité du facteur peut ne pas être suffisante pour négocier avec eux pour lui fournir leur clé privée afin de générer à la volée de faux certificats valides (bien que tout soit possible). Il a trouvé un moyen plus facile. Il se rend dans son propre conseil de village, qui se trouve dans la hiérarchie des centres de certification au niveau le plus bas, et presse ou soudoie le conseil de village pour qu'il signe son certificat comme certificat d'un centre de certification intermédiaire. Maintenant, il peut écouter le trafic non seulement de Boris, mais en principe de n'importe quel sujet. La personne ne remarquera probablement rien, le navigateur n'émettra aucun avertissement.



Il s'agit d'un problème connu, et l'humanité essaie également de le combattre. Si de tels faux certificats, des centres intermédiaires et racine compromis sont trouvés, ces certificats doivent être marqués comme révoqués et compromis (certificats révoqués). Cela signifie qu'en plus de stocker les certificats racine, Boris doit toujours les synchroniser avec la liste en ligne des certificats révoqués - ce mécanisme est implémenté via les protocoles CRL (liste de révocation des certificats) et OCSP (Online Certificate Status Protocol) [4], qui, soit dit en passant, fonctionnent selon canal non protégé. Lorsque nous avons commencé à travailler activement sur le contrôle du trafic OUTPUT à l'aide de Dhound [5], nous avons remarqué des demandes périodiques sur le port 80. Si vous interdisez de telles demandes au niveau du pare-feu, certaines fonctions cessent de fonctionner, par exemple l'envoi de courrier. Le problème des certificats révoqués est qu'il y en a déjà un grand nombre: en 2013, il y avait environ 3 millions de certificats révoqués [6], 23 000 certificats Symantec révoqués rien qu'en 2018 [7]. Chrome a désactivé la fonction par défaut de vérification complète des certificats révoqués il y a quelques années [8] pour augmenter la vitesse de chargement des pages. Il s'avère que si notre facteur est découvert, le processus de prévention supplémentaire de ses actions sera long et pas toujours couronné de succès.

Conclusions

Le système SSL moderne est partiellement fermé et centralisé , ce qui est certainement l'une de ses faiblesses. Tant qu'il en sera ainsi, il y aura toujours une tentation pour les «personnes puissantes de ce monde» d'en tirer leurs avantages, sans accorder la priorité à la vie privée. Pourtant, leurs propres algorithmes de chiffrement seront créés au niveau national, dans le but d'isoler d'autres pays de leurs propres citoyens, et de le faire nous-mêmes. La compromission de nœuds clés peut faire tomber l'ensemble du système dans son ensemble. L'entropie et la complexité croissantes du système conduiront de plus en plus à son état instable et, finalement, à la mort du système.

Quelle sortie? Le passage d'un système SSL fermé et centralisé à un système plus transparent et distribué, qui, de par sa nature, ne pourra offrir d'avantages à aucune des parties. Ce sera peut-être une solution quelque peu similaire à celle qui implémente une blockchain ouverte.

PS. Le protocole SSL a des nuances plus complexes qui n'étaient pas mentionnées dans l'article. Mais le niveau d'information était suffisant pour révéler l'une de ses faiblesses. Y a-t-il d'autres faiblesses? Dans les articles suivants, nous examinerons.


Publié par Denis Koloshko, CISSP