it-swarm.com.de

Authentifizieren eines Proxyservers über HTTPS

Wenn Sie über HTTPS zu einer Website navigieren, erledigt der Webbrowser normalerweise viel Arbeit im Hintergrund - Aushandeln eines sicheren Kanals, Überprüfen des Zertifikats der Website, Überprüfen der Vertrauenskette usw.

Wenn Ihr Browser für die Verwendung eines Webproxys konfiguriert ist, unterstützt das aktuelle HTTP-Protokoll eine CONNECT-Methode. Auf diese Weise kann Ihr Browser den TLS-Tunnel zur Website einrichten, ohne dem Proxy den Anforderungsinhalt (außer dem Namen des Proxys) mitzuteilen Seite natürlich).

Was macht der Browser in Bezug auf die Identität des Proxyservers?
Wenn der Proxy kein Zertifikat hat, kann es möglicherweise von einem MitM verkörpert werden.
Selbst wenn der Proxy tut ein Zertifikat hat, ist es möglicherweise immer noch möglich, sich als solches auszugeben, wenn es nicht überprüft wird.

Definiert das Protokoll (oder ein begleitender RFC), wie damit umgegangen werden soll? Wie gehen gängige Webbrowser normalerweise damit um?
Wenn der Proxy kein Zertifikat hat, gibt es eine Rückmeldung an den Benutzer? Wenn der Proxy über ein Zertifikat verfügt, dieses jedoch ungültig ist, gibt es dann eine Rückmeldung?


Gibt es außerdem eine Möglichkeit, den Webproxy sicher zu authentifizieren, selbst wenn es sich bei der Anforderung um einfaches HTTP handelt?
Zum Beispiel eine Verbindung zum Proxy über HTTPS herstellen, obwohl die Anforderung an die Website über HTTP erfolgt ...


HINWEIS: Ich frage nicht, wie ich die Website identifizieren soll, ob sie über den Proxy getunnelt wird oder ob sie die SSL-Kette abfängt.
Vielmehr möchte ich die Identität des Proxy selbst überprüfen, um sicherzustellen, dass kein nicht autorisierter Server mich mitmacht ...

26
AviD

Wie üblich, beantworten wir zuerst die genaue Frage, die gestellt wurde.

Derzeit wird die Verwendung von HTTPS zum Herstellen einer Verbindung mit Proxy nicht allgemein unterstützt. Die Tintenfischdokumentation enthält einige Informationen zu diesem Thema; um es zusammenzufassen:

  • Chrome unterstützt dies, muss jedoch über ein Proxy-Autokonfigurationsskript konfiguriert werden, da keine GUI-Unterstützung vorhanden ist. Dies bedeutet auch nicht ​​bei Verwendung der "systemweiten Proxy-Konfiguration".

  • Firefox unterstützt es nicht, obwohl die Funktion seit 2007 als angefordert markiert ist. (UPDATE: nterstützt in FF 33 + )

  • Keine Angabe in anderen Browsern, was vermutlich "überhaupt keine Unterstützung" bedeutet.

Was Chrome tut, wenn ein "etwas ungültiges" Zertifikat für den Proxy auftritt, sollte getestet werden, aber es hängt wahrscheinlich von der genauen Browserversion ab (die sich ständig ändert, oft transparent) Betriebssystem (da die Zertifikatverarbeitung in der Regel an das Betriebssystem delegiert wird) und auf welche Weise das Zertifikat nicht gültig ist (abgelaufen, falscher Servername, unbekannter Vertrauensanker, ...). Außerdem gibt es ein inhärentes Chicken-and- Eiproblem hier: Die vollständige Zertifikatsüberprüfung, wie von X.509 vorgeschrieben, umfasst die Überprüfung des Widerrufs, dh das Herunterladen der CRL für alle Zertifikate im Pfad. Die URL für das Herunterladen der CRL befindet sich normalerweise in den Zertifikaten selbst. Wenn Sie jedoch einen Proxy für Ihren HTTP-Verkehr verwenden, muss der CRL-Download diesen Proxy durchlaufen ... und Sie haben das Proxy-Zertifikat noch nicht validiert. Kein Huhn, kein Ei.

Möglicherweise stellen wir auch fest, dass das Dateiformat für die automatische Proxy-Konfiguration das HTTPS-Proxy nicht wirklich unterstützt. Es gibt kein formales Standard für diese Datei, aber es ist üblich, einem alter Netscape-Entwurf zu folgen, der besagt, dass eine PAC-Datei eine Javascript-Funktion definiert, die Proxy zurückgeben kann Hostnamen und Ports, aber kein Protokoll. Also kein HTTPS. Für die HTTPS-Proxy-Unterstützung verwendet Chrome verwendet implizit eine Erweiterung dieser de facto Konvention, indem eine HTTPS-URL dort eingefügt wird, wo sie kein Recht hat, und auf die hofft Browser, um einen Sinn daraus zu machen.


Wie üblich, lassen Sie uns sehen, welche alternativen Vorschläge gemacht werden können.

Um eine geschützte Kommunikation zwischen dem Client und dem Proxy zu gewährleisten, können die beiden folgenden Lösungen angewendet werden:

  • Verwenden Sie ein VPN . Dies ist sehr allgemein gehalten und gilt, da es auf Betriebssystemebene ausgeführt wird, für alle Browser. Natürlich muss jeder, der das Ding auf dem Client installiert machine, über Administratorrechte auf diesem Computer verfügen (Sie können dies nicht als einfacher, nicht privilegierter Benutzer tun).

  • Verwenden Sie einen SSH-basierten SOCKS-Proxy . Führen Sie auf Ihrem Client-System Folgendes aus: ssh -N -D 5000 theproxy; Stellen Sie dann Ihren Browser so ein, dass localhost:5000 als SOCKS-Proxy verwendet wird. Diese Lösung setzt voraus, dass der Proxyserver (theproxy) ebenfalls ein SSH-Server ist und dass Sie über ein Konto verfügen und dass der SSH-Port nicht durch eine schlecht gelaunte Firewall blockiert wird.

Die SOCKS-Proxy-Lösung stellt sicher, dass der Datenverkehr über den Proxy-Computer geleitet wird, enthält jedoch nicht Caching. Dies ist einer der Gründe, warum wir normalerweise überhaupt einen Proxy verwenden möchten. Es kann jedoch mit einigen zusätzlichen Tools geändert werden. Beim SOCKS-Proxy wird der gesamte TCP/IP-Verkehr (generisch) über einen benutzerdefinierten Tunnel umgeleitet. Generische Unterstützung für Anwendungen ist möglich, indem die normalen Netzwerkaufrufe auf Betriebssystemebene durch Versionen ersetzt werden, die SOCKS verwenden. In der Praxis wird hierfür eine bestimmte DLL, die über die Standard-Betriebssystembibliotheken übertragen wird; dies ist wird in Unix-basierten Systemen unterstützt mit LD_PRELOAD Und verwendet Ich nehme an, dass dies auch mit Windows möglich ist. Die vollständige Lösung wäre also:

  • Sie verwenden einen SSH-basierten SOCKS-Tunnel von Ihrem Client zum Proxy-Computer.
  • Der SOCKS-Client DLL wird auf den Browser angewendet und so konfiguriert, dass localhost:5000 Als SOCKS-Proxy verwendet wird.
  • Der Browser möchte nur theproxy:3128 Als einfachen HTTP-Proxy verwenden.

Wenn der Browser dann surfen möchte, öffnet er eine Verbindung zu theproxy:3128, Die die DLL abfängt und zu einem SOCKS-Tunnel umleitet, den sie zu localhost:5000 Öffnet. Zu diesem Zeitpunkt erfasst SSH die Daten und sendet sie unter dem Schutz des SSH-Tunnels an theproxy. Die Daten werden an theproxy beendet. An diesem Punkt ist die Verbindung zu Port 3128 rein lokal ( somit immun gegen netzwerkbasierte Angreifer).

Eine andere Möglichkeit , Caching im SSH-SOCKS-Setup hinzuzufügen, besteht darin, ein transparenter Proxy anzuwenden. Squid kann das (unter dem Namen "Interception Caching").

Eine weitere Möglichkeit , das Caching mit SSH-Schutz durchzuführen, besteht darin, mithilfe von SSH einen generischen Tunnel von Ihrem Computer zum Proxy zu erstellen. Führen Sie Folgendes aus:

ssh -N -L 5000:localhost:3128 theproxy

und stellen Sie dann Ihren Browser so ein, dass localhost:5000 als HTTP Proxy (nicht SOCKS) verwendet wird. Dies gilt nicht für das Proxying auf alternativen Protokollen wie FTP oder Gopher, aber wer verwendet sie überhaupt?


Wie üblich, stellen wir jetzt die Frage.

Sie sagen, dass Sie sich vor einem Man-in-the-Middle-Angriff schützen möchten. Aber wirklich, der Proxy ist ​​ein MitM. Was Sie wirklich wollen, ist, dass der Proxy die Entität nur ist, die ein MitM ausführt. HTTPS zwischen dem Browser und dem Proxy (oder SSH-SOCKS oder einem VPN) kann nur die Verbindung zwischen dem Client und dem Proxy und überhaupt nicht zwischen dem Proxy und dem Zielwebserver schützen. Es wäre vermessen zu behaupten, dass MitM-Angriffe zuverlässig vereitelt werden, ohne zu berücksichtigen, was im Wide Internet passiert, das bekanntermaßen ein rauer Ort ist.

Verwenden Sie für einen umfassenden Schutz gegen MitM SSL, d. H. Durchsuchen Sie HTTPS-Webserver. Wenn Sie dies jedoch tun, ist ein zusätzlicher Schutz für den Browser-zu-Proxy-Link überflüssig.

Das Schützen des Datenverkehrs zwischen Browser und Proxy ist sinnvoll, wenn Sie Proxy-Authentifizierung berücksichtigen. Einige Proxys erfordern eine explizite Authentifizierung, bevor sie Zugriff auf ihre Dienste gewähren. Dies ist (war?) in großen Organisationen üblich, die einigen wenigen glücklichen (normalerweise dem Chef und seinen Lieblingsuntergebenen) "unbegrenzten Internetzugang" vorbehalten wollten. Wenn Sie ein Passwort an den Proxy senden, möchten Sie nicht, dass das Passwort ausspioniert wird, daher SSL. Ein Angreifer, der das lokale Netzwerk belauschen kann, steuert jedoch notwendigerweise einen lokalen Computer mit Administratorrechten (möglicherweise einen Laptop, den er selbst mitgebracht hat). Seine lästigen Kräfte gehen bereits weit über das bloße Auslaufen der Internetbandbreite hinaus. Die Einschränkung des Internetzugriffs auf einer pro Benutzer Basis ist modernen Betriebssystemen eher schlecht zugeordnet, die für viele Aufgaben, einschließlich Softwareupdates, in der Regel auf den Internetzugang angewiesen sind. Der Internetzugang wird effizienter auf pro Nutzung Basis gesteuert.

Daher denke ich, dass der Schutz des Zugriffs auf einen HTTP-Proxy hat ​​einige Vorteile, aber nur in eher ungewöhnlichen Szenarien. Insbesondere hat es sehr wenig damit zu tun, die meisten MitM-Angriffe zu besiegen.

25
Thomas Pornin

Chrome auf der Clientseite und Squid auf der Proxyseite können über https funktionieren. Weitere Informationen finden Sie unter Secure Web Proxy .

Ich hoffe, dass Chrome Sie vor einem ungültigen Proxy-Zertifikat warnt, aber keine Erfahrung mit diesem Setup hat und daher nicht bestätigen kann.

3
lubas

Alternativ zur Verwendung der Antwort von @Thomas Pornin (wo er die Verwendung von SSH vorschlug) können Sie den Servicebus verwenden, um eine transparente Verbindung von einem lokalen Port zu einem Remote-Server aufrechtzuerhalten.

Die "Authentifizierung" erfolgt, wenn die Proxy-Client-Software eine Verbindung zum Service-Bus herstellt. Der Endpunkt dieses Service-Busses kann ein beliebiges Objekt sein, z. B. ein Intranet, ein Unternehmens-Proxy usw. Sobald die Client-Software Sie authentifiziert, befindet sich ein Mini-VPN erstellt (genau wie SSH).

Erste Schritte

Dieser .NET-Client wird lokal installiert, und das Ziel ist ein Proxy oder ein anderes Gerät, dem Sie vertrauen müssen.

Port Bridge installieren

Hinweis: Ersetzen Sie SQL Client und 1433 mental durch einen Port Ihrer Wahl ... mit diesem TCP basierten Proxy ist alles gleich

Dieses Projekt ermöglicht mehreren NAT-Servern den Zugriff auf mehrere NAT-Clients über das Internet über eine einzige Servicebusverbindung.

alt text

Es ist eine ziemlich clevere Implementierung, die Sie wirklich zum Nachdenken anregen wird. Unten ist die Quelle

http://blogs.msdn.com/b/clemensv/archive/2009/11/18/port-bridge.aspx

... und eine andere Erklärung dafür.

http://brentdacodemonkey.wordpress.com/2010/05/05/Azure-appfabric-%e2%80%93-a-bridge-going-anywhere/

Es gibt auch ein verwandtes Projekt namens "SocketShifter" für Codeplex: http://socketshifter.codeplex.com/ Obwohl die Codeplex-Site die Verwendung von Portbridge empfiehlt, werden ab (August 2010) Check-Ins angezeigt. und nicht sicher, welches aktueller ist. Es kann sich lohnen, dies zu untersuchen.

0