Est-ce que HTTTPS se défende-t-il contre des attaques de SSLSniff?
http://www.thoughcrime.org/software/sslsniff/
Si j'ai un domaine sur ma liste HTTPS partout sur la liste, de sorte que théoriquement, cela ne puisse être visité que via une connexion HTTPS dans mon Firefox, puis une attaque SSLSNIFF pour réussir contre moi? L'attaquant pourrait-il obtenir des informations car la SSLSNIFF a dégradé la connexion de HTTPS à HTTP? Ou je suis "pleinement sûr" de ces types d'attaques lors de l'utilisation de HTTPS partout?
MISE À JOUR: Et que se passe-t-il si j'ai le domaine whitelisted dans https partout? [Les fichiers XML pourraient être créés]. Donc, le domaine ne serait disponible que via HTTPS.
La réponse courte est la suivante: Non, pas toujours. J'ai étudié ce sujet en profondeur et veuillez lire tout ce poste avant de former une conclusion.
SSLSniff est une preuve de plate-forme d'exploitation conceptuelle pour tirer parti des défauts de la PKI, telles que vulnérabilités dans OCSP ou l'attaque (ingénieuse) Null-préfixe Attack . Si vous utilisez un système entièrement corrigé, vous comprenez quelle erreur SSL signifie que vous êtes immunisé sur [~ # ~] la plupart [~ # ~ ~] (mais pas tous) de ces attaques Sans le besoin de https partout. Si vous n'êtes pas corrigé contre l'attaque de certificat NULL-PREFIX, le certificat apparaîtra valide et HTTPS partout sera inutile. Si vous ne comprenez pas ce que signifie une erreur SSL, alors https partout est inutile contre SSLSniff.
Ce que je pense, c'est plus concernant que SSLSniff est SSLStrip , qui est également écrit par Moxie Marlinspike et introduit dans ses discussions - Nouvelles astuces pour vaincre SSL dans la pratique . Cet outil ne causera pas d'erreurs SSL. Ceci exploitant, http/https la couche d'application. Si vous chargez une page sur HTTP, il réécrirea la page Supprimer les liens HTTPS. Cela passera plus loin et changera le fichier Favicon.ico vers une image d'une serrure, pour tromper les utilisateurs novices. Assez simple, mais des conséquences absolument dévastatrices. En réponse à cette attaque, Google a introduit la Strict Security de la couche de transport (STS), qui ressemble beaucoup à HTTPS partout mais intégré au navigateur. Il convient également de noter que HTTPS partout est vraiment bon une défense contre l'attaque SSLStrip. En fait, il s'agit de la solution d'EFP aux attaques telles que SSL Strip ainsi que négligente Owasp A9 - Protection insuffisante de la couche de transport Violations.
Alors, quand https partout et STS échoue-t-il? Pourquoi pas https://stackoverflow.com . Si vous remarquez, ils utilisent un certificat auto-signé. Jeff Atwood lui-même ne se soucie pas de cette question . Étant donné que ce site Web utilise un certificat auto-signé, http partout utilisera de force HTTPS, mais l'attaquant peut toujours utiliser SSLSNIFF pour livrer son propre certificat auto-signé et que HTTPS ne parviendrait donc pas à protéger quelqu'un de votre compte Stackoverflow.
D'accord, alors à ce stade, vous vous dites probablement à vous-même. "Eh bien c'est pourquoi nous avons un PKI!". Eh bien, sauf que le PKI n'est pas parfait. L'un des créateurs de HTTPS a déclaré "le PKI était plus d'une ondulation de dernière minute" (voir: SSL et l'avenir de l'authenticité ). Dans ce discours, Moxie a posé une bonne question, est une PKI vraiment la meilleure solution? Je veux dire que nous rencontrons des problèmes avec CAS comme Diginotor étant piraté . Lorsqu'un CA est piraté, l'attaquant peut créer un certificat valide, puis https partout est totalement inutile, un attaquant peut toujours utiliser SSLSniff, car il a un certificat "valide". Le Observatoire SSL d'EFP démontre ce qu'est un gâchis tangelé le système PKI. Je veux dire vraiment, qu'est-ce que l'arrêt de la Chine de créer un certificat pour gmail.com? Eh bien, l'EFF propose le Projet Sovereign Keys et je pense que c'est une bonne idée. Outre le fait que les touches souveraines n'existent pas encore, il y a un autre problème, Les touches souveraines n'aident pas les certificats auto-signés comme celui utilisé par https://stackoverflow.com ! Cependant, Moxie pensa à cette situation et a proposé une solution qu'il appelle convergence . La convergence s'appuie sur les masses de confiance. L'hôte sera contracté de plusieurs connexions autour de la planète, si l'un d'entre eux voit un certificat auto-signé différent, vous savez qu'une attaque de MITM a lieu. Avoir un avertissement que quelque chose ne va pas, c'est beaucoup mieux que rien.
En résumé, il y a des problèmes fondamentaux https partout. Lorsqu'il y a une vulnérabilité dans des logiciels utilisés pour valider les certificats. Lorsque l'utilisateur ne comprend pas les répercussions d'une défaillance SSL. Quand un certificat auto-signé est utilisé. Ensuite, lorsque notre PKI compromis est utilisé contre vous. C'est un problème grave et des personnes intelligentes travaillant à la fixer, cela inclut l'EFF et l'auteur de SSLStrip, Moxie Marlinspike.
" HTTPS Everywhere " est uniquement sur l'utilisation de SSL chaque fois qu'il est possible - à savoir automatiquement en utilisant la version SSL d'un site si elle existe, même si le lien que vous avez saisi ou choisi est pour le site non-SSL du même nom. C'est tout " HTTPS Everywhere " ne.
" Sslsniff " est un outil d'attaque pour les connexions SSL Hijack. Il a besoin de deux choses:
- Une façon d'intercepter le trafic à faible niveau entrant et sortant entre le client et le serveur attaqué; sslsniff repose essentiellement sur l'usurpation d'identité ARP pour que, si l'attaquant doit être sur le même réseau local que le client ou le serveur.
- L'insertion dans le navigateur client d'une autorité de certification racine que les contrôles attaquant, ou exploiter un trou de sécurité dans le code de validation du certificat dans le navigateur client. Le modèle de sécurité SSL repose sur le client la validation du certificat en ce qui concerne son a priori connus certificats de CA racine; sslsniff est d'utiliser un certificat de faux généré à la volée, mais ce certificat doit encore être acceptable pour le client.
Il n'y a donc aucun lien entre sslsniff et HTTPS Everywhere. sslsniff fait non dégrader les connexions HTTPS à HTTP; du point de vue à la fois le client et le serveur, il est toujours SSL tout le chemin, et HTTPS Everywhere se sentirait parfaitement heureux avec elle. sslsniff est " juste " un outil pour les violations de levier dans le modèle de validation de certificat SSL utilisations pour assurer la sécurité.
... Puis une attaque SSLSniff pourrait-elle réussir contre moi?
Oui.
L'attaquant peut-il obtenir des informations car la SSLSniff a dégradé la connexion de HTTPS à HTTP?
Oui.
Permettez-moi d'ajouter que votre description ne convient pas exactement à la façon dont "SSLSNIFF" fonctionne. SSLSniff agit plus comme un proxy interceptant le trafic SSL, au lieu de simplement dégrader votre connexion. En d'autres termes: SSLSniff désactive plus que les certificats plus qu'avec la connexion HTTPS elle-même.
Cela signifie que votre "addon" pourrait en fait penser que tout va bien, alors que votre connexion est aussi non sécurisée que possible et que vous ne le sauriez pas.
Ou je suis "pleinement sûr" de ces types d'attaques lors de l'utilisation de HTTPS partout?
no.
Ne vous attendez jamais à un "addon de navigateur" pour fournir "protection du système".
Pour vous donner une perspective humaine: vous n'enverriez pas de cartes de garçons à la guerre non plus, n'est-ce pas? Bien sûr que non, car ils ne seraient pas assez aptes à gérer le travail. Eh bien, aucun addon de navigateur simple en ce qui concerne la sécurité SSL.
Pensez-y: toute personne qui joue avec votre navigateur pourrait gâcher l'addon. Dans le pire scénario, l'addon pourrait être modifié pour ne pas vous avertir que vous avez "perdu" votre connexion SSL sécurisée tout en naviguant et que vous ne le sauriez pas. Tout virus, un logiciel malveillant ou même un nouvel intervalle de navigateur serait capable (selon le but malveillant individuel) de gâcher votre système ... y compris le logiciel de votre système (qui inclut votre navigateur Web et ses advons et plugins).
MISE À JOUR: Et que se passe-t-il si j'ai le domaine whitelisted dans https partout? [Les fichiers XML pourraient être créés]. Donc, le domaine ne serait disponible que via HTTPS.
Revenir à votre cas et exemple: vous vous inquiétez de la connexion HTTPS. Votre navigateur peut utiliser cette connexion, mais il ne peut pas être sûr que les données d'envoi ou de réception ne sont pas interceptées et que vous ne pouvez aucun addon. En fait, la détection d'une telle "interception" peut déjà être assez difficile, même lorsque vous utilisez des "outils du commerce". Votre WebBrowser et tous les advons de l'extérieur ne fournissent aucun moyen de détecter une telle "attaque". Pas encore de toute façon ... SSLSniff a été fait pour montrer la faiblesse des connexions HTTPS (qui influence non seulement les webrowsers). Il reste à voir si les vendeurs de navigateurs pourront trouver un "correction" solide à de telles vulnérabilités. Surtout, puisqu'il s'agit moins d'un problème de navigateur, mais plutôt d'une "connexion" et de "sécurité du réseau". Et quand vous avez vérifié http://www.thoughcrime.org/software/sslsniff/ , vous aurez vu qu'il y a déjà plus de difficulté à nous attendre au coin de la rue. Ceci est affiché par la fonctionnalité supplémentaire que l'outil SSLSNIFF a gagné ... Juste pour afficher des problèmes liés tels que celui que vous avez récemment appris et espérait corriger en utilisant votre addon de navigateur.
Quoi qu'il en soit, laissez-moi rester court en répétant moi-même: Ne vous attendez jamais à un "addon de navigateur" à fournir "protection du système". Vous pouvez ou non l'aimer , mais c'est la réponse la plus courte à votre question, en l'enveloppant dans une seule ligne de texte compréhensible. Le reste de ma réponse assez longue est simplement utile décoration informations pour fournir des idées si nécessaire.
@Lancebaynes, est-il possible que vous vouliez vraiment poser des questions sur SSLStrip , plutôt que SSLSNIFFF ?
SSLSniff exploits ne vulnérabilité très spécifique dans Microsoft IE6. Ceci est fixé dans toutes les versions modernes de IE, et il n'a jamais affecté aucun autre navigateur - en particulier, il n'a jamais affecté Firefox.
Https partout est un complément qui est disponible pour Firefox. Il n'est pas disponible pour IE. Par conséquent, HTTPS partout est complètement sans pertinence pour la défense contre une vulnérabilité dans IE. C'est comme des pommes et des oranges. Il n'ya rien d'adjonctif de Firefox uniquement pourrait faire pour se défendre contre une vulnérabilité IE seulement.
Je soupçonne que vous vouliez vous poser de question sur SSLStrip. SSLStrip est une attaque beaucoup plus grave qui reste dangereuse aujourd'hui. C'est une attaque homme-intermédiaire qui convertit vos connexions HTTPS en connexions HTTP (ou convertissez-les en connexions HTTPS sur un autre site que l'attaquant contrôle et dont le nom de domaine semble suffisamment similaire pour ne pas remarquer). Cette attaque est dévastatrice et difficile pour les utilisateurs de détecter.
HTTPS partout est conçu pour se défendre contre des attaques de type SSLStrip. La façon dont il fonctionne est d'avoir une grande base de données sur laquelle les sites Web prennent en charge HTTPS. Si le site Web prend en charge HTTPS, https partout où votre navigateur utilise uniquement HTTPS pour vous connecter: elle ne permettra pas à votre navigateur de se connecter sur HTTP non crypté. Ainsi, https partout est partiellement utile pour arrêter ces types d'attaques.
HSTS est une autre défense contre les attaques de type SSLStrip. HSTS est pris en charge sur tous les navigateurs modernes (ce qui est un avantage sur HTTPS partout). Cependant, la TVHS oblige que le site opte dans la protection (qui est un désavantage comparé à HTTPS partout).
Plus de lecture:
Vous seriez toujours vulnérable à SSLSNIFF.
SSLSNIFF utilise ARP-Spoof pour être le MITM. Ce que cela signifie, c'est que votre vulnérabilité est au réseau local (ou wifi).
Je n'ai pas testé la dernière version SSLSniff pour savoir comment elle gère l'avertissement de certificat, mais c'est la seule indication qu'un utilisateur a le problème de la configuration de la connexion sécurisée sur le site distant.