Comment fonctionne SSLstrip?
J'ai lu sur SSLstrip et je ne suis pas sûr à 100% de ma compréhension du fonctionnement.
De nombreux documents semblent indiquer qu'il remplace simplement les occurrences de "https" par "http" dans le trafic auquel il a accès. Ainsi, une URL de passage telle que " https://Twitter.com " serait transmise à la victime sous la forme " http://Twitter.com ".
À ce stade, SSLstrip continue-t-il de communiquer avec Twitter via HTTPS en notre nom? Quelque chose comme ça:
Victim <== HTTP ==> Attacker <== HTTPS ==> Twitter
Ou est-ce simplement le fait que le client communique maintenant avec Twitter via HTTP qui nous donne accès au trafic?
Victim <== HTTP ==> Attacker <== HTTP ==> Twitter
Je suppose que ce serait la première option où l'attaquant continue de communiquer avec Twitter via HTTPS car il est appliqué par Twitter, mais je voudrais juste quelques éclaircissements, merci.
Vous devriez regarder le discours de Moxie Marlinspike Vaincre SSL en utilisant SSLStrip . En bref, SSLStrip est un type d'attaque MITM qui force le navigateur d'une victime à communiquer avec un adversaire en texte brut via HTTP, et l'adversaire procède par procuration au contenu modifié d'un serveur HTTPS. Pour ce faire, SSLStrip "supprime" https:// URL et les transformer en http:// URL.
HSTS est une solution proposée à ce problème.
Parler des solutions possibles: La seule façon vraiment fiable d'empêcher/détecter le stripage SSL est d'utiliser une communication toujours cryptée et une authentification latérale du TLS (utilisez essentiellement l'échange de clés TLS, mais remplacez l'authentification basée sur PKI/certificat par un utilisateur ou un appareil) authentification). Cela signifie en pratique qu'après un échange de clé, le serveur et l'utilisateur se retrouvent avec certains secrets ou clés partagés. Le client et le serveur utilisent ensuite un canal d'authentification discret (par exemple en utilisant SSH ou d'autres méthodes d'authentification asymétrique forte) et authentifient à la fois leur identité et les clés TLS. Si les clés sont les mêmes, vous avez une certitude de canal chiffré de bout en bout à 100%.
S'il y a un homme au milieu, il pourrait faire 2 vecteurs d'attaque:
MITM pourrait mettre fin à la communication TLS avec le serveur à son stade et laisser l'utilisateur communiquer via HTTP. Cela ne provoque aucune alerte dans TLS/HSTS traditionnel. Cependant, cela sera découvert par l'authentification du canal latéral, car le serveur et le client ont des clés TLS différentes (clé 1 et sans clé).
Le MITM pourrait utiliser un certificat falsifié ou volé. Cela peut ou non déclencher une alerte, selon le certificat utilisé (cela peut être de plus en plus facile grâce à l'initiative Let's Encrypt). Cette attaque serait à nouveau découverte par le TLS authentifié sur le canal latéral, car le serveur aurait une clé différente de celle du client (le serveur a la clé1, MITM a la clé1 pour le serveur, MITM a la clé2 pour le client, le client a la clé2).
Cela tue les certificats SSL en bonus et cela fonctionnerait également avec les CDN Veuillez noter que cette solution n'est pas à l'abri des backdoors au cryptage.
Je pense qu'il est important de noter que la suppression est effectuée sur les charges utiles client vers serveur et nécessite que le client demande d'abord le contenu HTTP.
En utilisant l'exemple Twitter, le client devra d'abord demander http://www.Twitter.com - lorsque le site redirige le client vers HTTPS SSL Strip supprimera les "s" dans la réponse de telle sorte que le client continuera à demander du contenu HTTP, pas HTTPS.
Si un client demandait https://www.Twitter.com (ou HSTS est en cours d'utilisation), une attaque SSL MiTM serait nécessaire pour intercepter la réponse, ce qui va à l'encontre du but de cette attaque.
HSTS est un simple "en-tête http" qui peut être modifié et modifié par le MITM
Préférez les addons comme HTTPnowhere ou HTTPS Everywhere, avec 90% de succès ... Un autre type d'addon est https://addons.mozilla.org/en-US/firefox/addon/enable-disable-weak-ssl -cip / pour chiffrer les données après la négociation de la négociation SSL.
Évident en tant que client, vous êtes en position INFÉRIEURE et les routeurs entre vous et Internet sont facilement contrôlés. Donc, comprenez que les clients ont peu de ressources pour contrôler le trafic ... et pour cela seule la meilleure solution est VPN/Stunnel .. mais ne sait jamais si les personnes NSA/ISP/préviligied ont le secret magique pour intercepter et décrypter cette communication ..