Was ist SSL, wenn Fiddler 2 alle Anrufe über HTTPS entschlüsseln kann?

Question

Ich habe vor einiger Zeit eine Frage dazu gestellt, wie ich meine http-Anforderungsaufrufe ausblenden und in meiner Anwendung sicherer machen kann. Ich wollte nicht, dass Leute fiddler 2 benutzen, um den Anruf zu sehen und einen Autoresponder einzurichten. Jeder hat mir gesagt, dass ich SSL gehen soll und Anrufe werden versteckt und Informationen sicher aufbewahrt.

Ich kaufte und installierte ein SSL-Zertifikat und bekam alles eingerichtet. Ich habe fiddler 2 gebootet und eine Testanwendung ausgeführt, die sich mit einem https-Webdienst verbindet und mit einem https-PHP-Skript verbunden ist.

Fiddler 2 konnte nicht nur beide Anfragen erkennen, sondern auch entschlüsseln! Ich konnte alle Informationen zurück und viert sehen, was mich zu meiner Frage bringt.

Was ist der Sinn von SSL, wenn es keinen Unterschied zur Sicherheit macht. Mit oder ohne SSL kann ich alle Informationen zurück und viertens sehen und noch einen automatischen Antwortgeber einrichten.

Gibt es etwas in .NET Ich vermisse meine Anrufe besser über SSL zu verstecken?

EDIT

ich einen neuen Teil auf einige der Antworten aufgrund dieser Frage bin ich Zusatz erhalten haben. Was passiert, wenn eine App sich mit einem Webdienst verbindet, um sich anzumelden? Die App sendet dem Web-Service einen Benutzernamen und ein Passwort. Der Web-Service sendet dann Daten zurück an die App, die gute oder schlechte Login-Daten sagen. Selbst wenn man über SSL geht, kann die Person, die Fiddler 2 verwendet, einfach einen Autoresponder einrichten, und die Anwendung wird dann "geknackt". Ich verstehe, wie es nützlich sein kann, die Daten beim Debuggen zu sehen, aber meine Frage ist, was genau man tun sollte, um sicherzustellen, dass die SSL Verbindung zu der, die sie angefordert hat, ist. Grundsätzlich gesagt, es kann keinen Mittelmann geben.

Answer 1

Dies wird hier abgedeckt: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp

Fiddler2 stützt sich auf eine "Man-in-the-Middle" -Ansatz, um HTTPS Interception. In Ihrem Webbrowser ist Fiddler2 der sichere Webserver und der Webserver Fiddler2 ahmt den Webbrowser nach. Um sich als Webserver auszugeben, generiert Fiddler2 dynamisch ein HTTPS-Zertifikat.

Im Wesentlichen vertrauen Sie manuell, was Zertifikat Fiedler liefert, wird das gleiche gilt, wenn Sie manuell Zertifikat von zufälliger Person akzeptieren, die nicht Domain-Namen entspricht.

EDIT: Es gibt Möglichkeiten, Fiddler/Man-in-the-Middle-Angriff zu verhindern - d. H. In benutzerdefinierten Anwendung mit SSL kann man bestimmte Zertifikate für die Kommunikation benötigt. Im Fall von Browsern haben sie eine Benutzeroberfläche, um den Benutzer über eine fehlende Übereinstimmung des Zertifikats zu benachrichtigen, aber eventuell eine solche Kommunikation zuzulassen.

Als öffentlich verfügbares Beispiel für explizite Zertifikate können Sie versuchen, Azure-Dienste (d. H. Mit PowerShell-Tools für Azure) zu verwenden und den Datenverkehr mit Fiddler zu überwachen. Es scheitert aufgrund der expliziten Cert-Anforderung.

Answer 2

Sie können Ihren Web-Service so einrichten, dass eine clientseitige Zertifizierung für die SSL-Authentifizierung sowie die Serverseite erforderlich ist. Auf diese Weise kann Fiddler keine Verbindung zu Ihrem Dienst herstellen. Nur Ihre Anwendung, die über das erforderliche Zertifikat verfügt, kann eine Verbindung herstellen.

Natürlich, dann haben Sie das Problem, wie das Zertifikat in der App zu schützen, aber Sie haben dieses Problem jetzt mit Ihrem Benutzernamen & Passwort sowieso. Jemand, der Ihre App wirklich knacken möchte, könnte mit Reflector loslegen oder sogar eine Speichersuche nach dem privaten Schlüssel durchführen, der dem clientseitigen Zertifikat zugeordnet ist.

Es gibt keinen wirklichen Weg, um diese 100% kugelsichere zu machen. Es ist das gleiche Problem, das die Filmindustrie beim Sichern von DVD-Inhalten hat. Wenn Sie über Software verfügen, die die DVD entschlüsseln und den Inhalt wiedergeben kann, kann jemand einen Speicherauszug erstellen, während diese Software aktiv ist, und den Entschlüsselungsschlüssel finden.

Answer 3

Der Punkt von SSL/TLS im Allgemeinen ist, dass der gelegentliche Lauscher mit Wireshark Ihre Nutzlasten nicht sehen kann. Fiddler/Burp bedeutet, dass du mit dem System interagiert hast. Ja, es ist eine sehr einfache Interaktion, aber es erfordert (eine) der Systeme, kompromittiert zu werden.

Wenn Sie die Sicherheit erhöhen möchten, indem Sie diese MITM-Programme auf solch grundlegender Ebene unbrauchbar machen, benötigen Sie eine Client-Zertifikat-Authentifizierung (2-Wege-SSL) und pinnen sowohl die Server- als auch die Client-Zertifikate (z. B. nur das bestimmte Zertifikat ist gültig für die Kommunikation). Sie würden auch die mit den öffentlichen Schlüsseln jeder Partei übertragenen Payloads verschlüsseln und sicherstellen, dass sich die privaten Schlüssel nur auf den Systemen befinden, zu denen sie gehören. Auf diese Weise kann der Angreifer, selbst wenn eine Partei (Bob) kompromittiert ist, nur sehen, was an Bob gesendet wird und nicht, was Bob an Alice sendet. Sie würden dann die verschlüsselten Payloads nehmen und die Daten mit einem verifizierbaren Zertifikat signieren, um sicherzustellen, dass die Daten nicht manipuliert wurden (es gibt viele Diskussionen darüber, ob zuerst verschlüsselt oder zuerst signiert werden soll, btw). Darüber hinaus können Sie die Signatur mit mehreren Durchläufen von etwas wie sha2 hashen, um sicherzustellen, dass die Signatur "as-sended" ist (obwohl dies weitgehend ein obskurer Schritt ist).

Dies würde Sie so weit in der Sicherheit Weise wie erreichbar vernünftig, wenn Sie nicht (eine) der Kommunikationssysteme steuern.

Wie bereits erwähnt, wenn ein Angreifer das System steuert, steuert er den RAM und kann alle Methodenaufrufe im Speicher ändern.