Kaspersky Antivirus «Scanner de la connexion sécurisée» comme brisé que les Superfish?
J'ai beaucoup lu sur les Superfish (et une annonce similaire) récemment et je comprends essentiellement la vulnérabilité aux attaques de MITM. Mais je me demande en fait si le " Secure Connection Scan " de Kaspersky Antivirus est aussi brisé que l'exemple des Superfish?
Je veux dire que Kaspersky installe un certificat racine sur mon ordinateur et "homme dans les intermédiaires" toutes les connexions à numériser pour les logiciels malveillants. Pour ma compréhension, ce n'est pas mieux que la catastrophe des Superfish ... Qu'est-ce qui rend Kaspersky plus sécurisé?
Espérons que quelqu'un fera les tests et donnera une réponse définitive pour Kaspersky pour vous. Pendant ce temps, voici une réponse pour le cas général:
cela dépend.
Exécution d'un proxy SSL contre vous-même affaiblir votre posture de sécurité? Certainement. Un produit donné affaiblira-t-il votre posture de sécurité aussi mauvaise que les Superfish? C'est très dépendant de la mise en œuvre, et également soumis aux menaces contre le produit individuel lui-même.
Les Superfish ont échoué à deux points critiques.
Il a utilisé un mot de passe faible pour protéger une clé privée qui n'était pas unique pour chaque système. Cela a abouti à la clé facilement épargnée et divulguée publiquement pour que quiconque puisse prétendre être votre proxy de Superfish Poisson autorisé.
Il n'a pas réussi à valider correctement certaines conditions sur les certificats SSL, ce qui a permis à la proxy des Superfish d'accepter des certificats non valides et de présenter le site Web à l'utilisateur final comme s'il était légitime.
Bien que la première partie soit une pause importante, c'est le deuxième bit qui est sans doute la faille la plus critique. Sans la deuxième faille, les utilisateurs seraient toujours relativement bien protégés tant que la clé est restée secrète. (Principe de Kerckhoffs en action.) Toutefois, étant donné que la deuxième faille, un attaquant n'aurait même pas besoin de la clé de lancer une attaque convaincante d'un homme intermédiaire entre un utilisateur de Superfish et un site Web autrement sécurisé.
En tenant compte de cela, il y a quelques simples contre-mesures qui peuvent protéger largement les utilisateurs.
Générez des touches racines uniques pour chaque installation, protégez-les avec des mots de passe forts et uniques et ne distribuez pas les clés au-delà de l'hôte sur lequel réside le proxy. Cela empêche la divulgation de la clé d'un système d'avoir un impact substantiel sur la sécurité des autres.
Validez correctement les certificats SSL et fournissez les notifications appropriées à l'utilisateur lorsque quelque chose est absent. Sans cela, la clé ne compte pas beaucoup - un attaquant doit simplement convaincre le proxy que leur site est légitime, en exploitant une faille dans le processus de validation et le proxy présentera le site en tant que tel à l'utilisateur.
Obtenez ces choses correctes et vous êtes prêt à partir - non? Eh bien, pas tout à fait.
Voir, maintenant, nous rencontrons un problème avec la présentation du certificat à l'utilisateur. Parce que le proxy doit intercepter le trafic et la reconquérir de ses propres informations d'identification, l'utilisateur ne voit toujours jamais les informations d'identification originales du site. Chaque site semble avoir un certificat délivré par le proxy, avec date et horodatage en fonction du moment où le proxy a généré le CERT MITM. Cela supprime complètement la capacité de l'utilisateur à décider des chemins de CAS ou de confiance qu'ils détiennent crédibles ou de reconnaître les modifications apportées au certificat au fil du temps. Cela empêche également la corroboration du certificat avec d'autres entités externes de confiance.
Prenez le cas de Diginotar, où un attaquant a pu utiliser une racine de confiance couramment approuvée pour générer des certificats de faux certifiés pour Google Services. Sans proxy SSL en place, l'utilisateur peut être alerté d'une activité suspecte par un ou plusieurs de plusieurs moyens.
- Un plug-in ou une autre utilitaire de navigateur pourrait comparer le certificat à d'autres certificats précédemment observés sur le même site par le même utilisateur et alerter l'utilisateur à des modifications inattendues. (E.G.: DIFFÉRENTS CA qu'auparavant, un nouveau certificat publié de manière lointabilité avec l'expiration du certificat précédent, etc.)
- Un plugin de navigateur ou une autre utilité pourrait comparer le certificat aux certificats rapportés sur ce site, par une communauté en ligne ou une autre autorité de confiance, et d'alerter l'utilisateur à des divergences inattendues (par exemple: 98% des utilisateurs de votre région signalent un certificat différent de celui de la celui que vous voyez).
- Un utilisateur diligent peut vérifier fréquemment le certificat et remarquer les changements inhabituels.
Avec un proxy, toutes ces options ne sont plus disponibles pour l'utilisateur final. Le proxy lui-même peut être configuré pour surveiller et alerter, ces problèmes (tout comme certains plugins de navigation), mais finalement, l'utilisateur final perd toujours la capacité de la voir pour eux-mêmes.