À quoi sert SSL si le violoneux 2 peut décrypter tous les appels via HTTPS?
J'ai posé une question ici il y a quelque temps sur la façon de masquer mes appels de demande http et de les rendre plus sécurisés dans mon application. Je ne voulais pas que les gens utilisent fiddler 2 pour voir l'appel et configurer un répondeur automatique. Tout le monde m'a dit d'aller SSL et les appels seront cachés et les informations protégées.
J'ai acheté et installé un certificat SSL et j'ai tout configuré. J'ai démarré fiddler 2 et exécuté une application de test qui se connecte à un service Web https ainsi qu'à un script php https.
Fiddler 2 a non seulement pu détecter les deux requêtes, mais aussi les décrypter! J'ai pu voir toutes les informations remonter et quatrième, ce qui m'amène à ma question.
Quel est l'intérêt d'avoir SSL si cela ne fait aucune différence pour la sécurité. Avec ou sans SSL, je peux voir toutes les informations remonter et quatrième et encore configurer un répondeur automatique.
Y a-t-il quelque chose dans .NET qui me manque pour mieux cacher mes appels via SSL?
MODIFIER
J'ajoute une nouvelle partie à cette question en raison de certaines des réponses que j'ai reçues. Que faire si une application se connecte à un service Web pour se connecter. L'application envoie au service Web un nom d'utilisateur et un mot de passe. Le service Web renvoie ensuite des données à l'application indiquant de bonnes ou mauvaises données de connexion. Même si vous passez par SSL, la personne utilisant fiddler 2 peut simplement configurer un répondeur automatique et l'application est alors "piratée". Je comprends comment il pourrait être utile de voir les données dans le débogage, mais ma question est de savoir exactement ce que l'on doit faire pour s'assurer que le SSL se connecte à celui qu'il demandait. Fondamentalement, il ne peut pas y avoir d'intermédiaire.
Ceci est couvert ici: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp
Fiddler2 s'appuie sur une approche "homme au milieu" pour l'interception HTTPS. Pour votre navigateur Web, Fiddler2 prétend être le serveur Web sécurisé et pour le serveur Web, Fiddler2 imite le navigateur Web. Afin de prétendre être le serveur Web, Fiddler2 génère dynamiquement un certificat HTTPS.
Essentiellement, vous faites confiance manuellement au certificat fourni par Fiddler, il en sera de même si vous acceptez manuellement le certificat d'une personne aléatoire qui ne correspond pas au nom de domaine .
EDIT: Il existe des moyens d'empêcher l'attaque Fiddler/man-in-the-middle - c'est-à-dire que dans une application personnalisée utilisant SSL, il peut être nécessaire d'utiliser des certificats particuliers pour la communication. Dans le cas des navigateurs, ils ont une interface utilisateur pour informer l'utilisateur de la non-concordance des certificats, mais éventuellement autoriser une telle communication.
En tant qu'exemple accessible au public pour les certificats explicites, vous pouvez essayer d'utiliser les services Azure (c'est-à-dire avec les outils PowerShell pour Azure) et renifler le trafic avec Fiddler. Il échoue en raison d'une exigence explicite de cert.
Vous pouvez configurer votre service Web pour exiger une certification côté client pour l'authentification SSL, ainsi que du côté serveur. De cette façon, Fiddler ne pourrait pas se connecter à votre service. Seule votre application, qui possède le certificat requis, pourra se connecter.
Bien sûr, alors vous avez le problème de savoir comment protéger le certificat dans l'application, mais vous avez maintenant ce problème avec votre nom d'utilisateur et votre mot de passe. Quelqu'un qui veut vraiment cracker votre application pourrait essayer Reflector, ou même faire une recherche dans la mémoire pour la clé privée associée au certificat côté client.
Il n'y a aucun moyen réel de rendre cette preuve à 100% pare-balles. C'est le même problème que l'industrie du cinéma a avec la sécurisation du contenu DVD. Si vous disposez d'un logiciel capable de déchiffrer le DVD et de lire le contenu, quelqu'un peut effectuer un vidage de la mémoire pendant que ce logiciel est en action et trouver la clé de déchiffrement.
Le but de SSL/TLS en général est que les espions occasionnels avec Wireshark ne puissent pas voir vos charges utiles. Fiddler/Burp signifie que vous avez interagi avec le système. Oui, il s'agit d'une interaction très simple, mais elle nécessite que l'un des systèmes soit compromis.
Si vous souhaitez améliorer la sécurité en rendant ces programmes MITM inutiles à un niveau aussi basique, vous auriez besoin d'une authentification par certificat client (SSL bidirectionnel) et épingler les certificats serveur et client (par exemple, exiger que seul le certificat particulier soit valide pour les communications). Vous crypteriez également les charges utiles transférées sur le câble avec les clés publiques de chaque partie et vous assureriez que les clés privées ne résident que sur les systèmes auxquels elles appartiennent. De cette façon, même si une partie (Bob) est compromise, l'attaquant ne peut voir que ce qui est envoyé à Bob, et non ce que Bob a envoyé à Alice. Vous prendriez ensuite les charges utiles chiffrées et signeriez les données avec un certificat vérifiable pour vous assurer que les données n'ont pas été falsifiées (il y a beaucoup de débat sur le fait de chiffrer d'abord ou de signer d'abord, entre autres). En plus de cela, vous pouvez hacher la signature en utilisant plusieurs passes de quelque chose comme sha2 pour vous assurer que la signature est `` telle qu'elle est envoyée '' (bien que ce soit en grande partie une étape obscure).
Cela vous amènerait dans la mesure de la sécurité raisonnablement possible lorsque vous ne contrôlez pas (un) des systèmes communicants.
Comme d'autres l'ont mentionné, si un attaquant contrôle le système, il contrôle le RAM et peut modifier tous les appels de méthode en mémoire.