Quel est le degré de sécurité du protocole SSL ?

Question

Quel est le degré de sécurité du protocole SSL (Secure Socket Layer) ? Comme dans, combien faut-il pour craquer un mot de passe envoyé par SSL ?

Answer 1

En supposant que tout est configuré/sécurisé correctement et que nous parlons de clés de 128 bits, beaucoup plus long que l'âge de l'univers .

Je voudrais noter que les précédentes fissures dans le SSL s'est appuyé sur le "trou" dans MD5 ce qui a entraîné le changement de la méthode de validation de certains

Je voudrais aussi noter que cela ne vous libère pas de man-in-the-middle ou même quelqu'un qui détourne le certificat privé de l'entreprise cible (notez que les clés privées doivent être protégées par un certificat de sécurité). fort pour atténuer un tel risque, puis la clé est révoquée si un tel événement se produit). Vous trouverez ici un aperçu général du fonctionnement de SSL. .

Answer 2

SSLv2 a connu des problèmes avec des attaques MITM capables d'entraîner la négociation de chiffrements de moindre qualité. À l'époque, il s'agissait généralement d'une liste de chiffrements de "qualité export" qui étaient intentionnellement faibles et pouvaient être piratés par la seule force brute.

SSLv3/TLSv1 a effectivement résolu le problème de la négociation et, peu de temps après, un grand nombre de chiffrements de moindre qualité ont été retirés de la disponibilité, maintenant que les restrictions à l'exportation aux États-Unis ont été levées et que divers scanners de conformité sont apparus.

La génération de PRF dans SSL utilise à la fois MD5 et SHA1 afin d'éviter que le système ne soit compromis si l'un des algorithmes de hachage l'était suffisamment. Un moyen d'attaque contre SSL consiste à compromettre suffisamment les deux algorithmes utilisés dans la fonction PRF Je crois que c'est juste une sorte de XOR de l'entrée qui passe par les deux.

Les ciphers de chiffrement sont disponibles et négociés de manière dynamique, de sorte que toute analyse de la qualité des sessions chiffrées elles-mêmes doit prendre en considération la sélection des ciphers ou se concentrer sur les mécanismes menant à l'établissement de la clé de chiffrement de la session initiale.

(Vous pouvez compromettre un chiffre (RSA, AES, etc.) mais cela ne signifie pas nécessairement que le SSL lui-même est cassé).

À mon avis, les attaques cryptographiques les plus pratiques sur SSL sont les attaques par canal latéral contre des chiffrages spécifiques. L'AES, en particulier, est connu pour être vulnérable aux attaques temporelles. Celles-ci nécessitent généralement des réseaux de haute qualité à faible latence pour être exécutées (Ethernet local) Il existe des fonctions d'aveuglement dans de nombreux systèmes qui ajoutent simplement un retard artificiel au processus afin d'atténuer la possibilité de réussite des attaques temporelles. (En fait, le temps nécessaire à l'exécution de certaines séquences de code peut être utilisé pour récupérer suffisamment d'informations pour compromettre le système).

Et enfin, ma faiblesse personnelle préférée de SSL est les attaques contre la "fiabilité" du système. Quels que soient les algorithmes/chiffres utilisés, le cryptage est inutile sans confiance.

Bien sûr, vous pouvez établir une session cryptée sécurisée, mais si vous ne savez pas si vous parlez à une personne légitime ou à un attaquant, toute cette sécurité devient un presse-papiers inutile.

Aujourd'hui, nous sommes dans une situation où des dizaines d'autorités de certification sont répertoriées dans pratiquement tous les navigateurs de la planète. Sous chacune d'entre elles se trouvent plusieurs autorités de signature intermédiaires exploitées par chacune des autorités de certification/downlines.

Il y a eu des incidents où des bogues du système ou des CA et des revendeurs tout simplement paresseux ont fait que le système était grand ouvert, permettant la signature de demandes de certificats pour des domaines qui n'auraient pas dû être autorisés.

Il suffit de compromettre une AC, un intermédiaire, un revendeur, etc. pour compromettre l'ensemble de l'ancre de confiance (en fait la planète Terre). Cela peut être fait et a été fait : parfois accidentellement, parfois intentionnellement. Si vous utilisez IE, voyez par vous-même :

Outils-Options Internet-Certificats-Éditeurs non fiables... Oups...

Il existe des facteurs d'atténuation : dates d'expiration des certificats, listes de révocation, etc. mais à mon avis, la question de la confiance reste la principale vulnérabilité de l'ensemble du système.

Je pense qu'un individu ou un groupe déterminé, doté de bonnes compétences en ingénierie sociale ou d'armes automatiques, a plus de chances que d'autres d'obtenir la signature de tout certificat qu'il souhaite.

Answer 3

Steve Gibson a expliqué exactement comment le protocole fonctionne sur une récent podcast de Security Now . Si les détails vous intéressent, cela vaut vraiment la peine de l'écouter.

Answer 4

D'un point de vue mathématique, en supposant que vous disposez d'une mise en œuvre correcte et en ignorant la possibilité d'attaques par canal latéral actuellement inconnues, ou de vulnérabilités mathématiques actuellement inconnues, il devrait falloir beaucoup plus de temps que l'âge de l'univers pour forcer une clé privée.

Cependant, les attaques par canal latéral et les autres formes d'attaques contre la mise en œuvre sont très réelles et doivent être prises au sérieux. Il s'agit notamment d'attaques de type "man in the middle", d'autorités de certification SSL malveillantes, d'attaques physiques contre l'hôte, etc.

Answer 5

Cela dépend de la longueur de la clé, de l'algorithme et de la ferme de serveurs pour le décrypter.