Zurück zum Blog

Browser-Proxy-Erweiterung auswählen: Protokoll, Wirkungsbereich und Selbsttest

Die größte Falle bei Browser-Proxy-Erweiterungen ist der Wirkungsbereich: Sie übernehmen nur den Browser-Datenverkehr und können bei nicht passenden Regeln auf eine Direktverbindung zurückfallen. Der Artikel ordnet Erweiterungen nach Einsatzzweck, nennt Bewertungskriterien wie Protokoll, Authentifizierung, Berechtigungen und Wartungsstand und beschreibt Selbsttests für Ausgangs-IP und WebRTC-Lecks.

Browser-Proxy-Erweiterungen haben eine oft übersehene Grenze: Sie übernehmen nur die Anfragen, die der Browser selbst stellt. Systemupdates, Desktop-Clients und andere Apps laufen weiterhin über den ursprünglichen Weg. Überlege zuerst genau, was über den Proxy laufen soll, und wähle dann das Werkzeug – das erspart später viel Fehlersuche.

Zuerst nach Einsatzzweck in drei Kategorien einteilen

Der häufigste Bedarf ist das Umschalten pro Website: Einige wenige Domains sollen über den Proxy laufen, alles andere verbindet sich direkt. Solche Szenarien werden über eine Regelliste gesteuert, und der Wert der Erweiterung liegt im schnellen Umschalten und in der Aufteilung nach Domain.

Die zweite Kategorie ist der globale Proxy, bei dem der gesamte Browser-Datenverkehr über einen einzigen Ausgangspunkt läuft. Die Einrichtung ist am einfachsten, aber der Preis ist direkt spürbar: Fällt der Ausgang aus, ist der Browser praktisch offline, was die alltägliche Nutzung instabil macht.

Die dritte Kategorie ist an eine Umgebung gebunden: Jedes Browser-Profil ist fest einem Ausgang zugeordnet, und die Profile beeinflussen sich gegenseitig nicht. So wird vorgegangen, wenn mehrere Konten oder mehrere Projekte parallel laufen; die Erweiterung ist hier eher eine Ergänzung, da der Ausgang selbst meist auf einer tieferen Ebene konfiguriert wird.

Worauf man bei der Bewertung einer Erweiterung achtet

Die Protokollunterstützung steht an erster Stelle. HTTP- und HTTPS-Proxys verarbeiten nur TCP, während SOCKS5 allgemeiner ist; die UDP-Unterstützung hängt jedoch von der Implementierung ab, und viele Erweiterungen lassen UDP einfach durch oder verwerfen es vollständig. Das ist später wichtig, denn es hängt direkt damit zusammen, ob WebRTC leakt.

Die Authentifizierungsmethode sollte man genau prüfen. Anmeldung mit Benutzername und Passwort ist bequem, doch die in der Erweiterung gespeicherten Zugangsdaten liegen lokal im Klartext oder nur schwach verschlüsselt vor, sodass sie von anderen Nutzern des Rechners gelesen werden können; die Authentifizierung über eine IP-Whitelist speichert nichts in der Erweiterung, dafür muss die Whitelist bei jedem Netzwerkwechsel neu gepflegt werden.

Der Wirkungsbereich ist die häufigste Fehlerquelle. Im Regelmodus gehen Domains, die auf keine Regel passen, standardmäßig direkt raus, und man weiß oft nicht, welche Domains eine Seite tatsächlich anfragt. Sobald eine HTTPS-Seite ihre Verbindung aufgebaut hat, sieht die Erweiterung nur die Domain, nicht den konkreten Pfad – die Idee, nach Pfad aufzuteilen, funktioniert also praktisch nicht.

Auch der Umfang der Berechtigungen gehört auf den Prüfstand. Wenn eine Proxy-Erweiterung zusätzlich Zugriff auf Daten aller Websites, Tab-Informationen oder die Zwischenablage anfordert, sollte man fragen, ob diese Rechte überhaupt mit der angeblich gebotenen Funktion zusammenhängen. Auch die Manifest-Versionsupgrades von Browser-Erweiterungen schränken verfügbare Schnittstellen weiter ein, weshalb manche älteren Erweiterungen ihre Architektur ändern mussten.

Bei der Wartungsaktivität zählt nicht, wie viele Changelog-Einträge es gibt, sondern ob jemand die Änderungen der Upstream-Seite nachvollzieht. Unter den Proxy-Erweiterungen wurde die Store-Version von Proxy SwitchyOmega entfernt, und ein von der Community gepflegter Fork (etwa die ZeroOmega-Linie) hat die weitere Anpassung übernommen; Erweiterungen wie FoxyProxy gibt es für mehrere Browser. Diese Beispiele sind neutral gemeint; welche besser passt, hängt weiterhin von den genannten Punkten ab.

Der Datenverkehr, den sie nicht abdeckt

Nach der Installation läuft der Browser selbst über den Proxy, doch andere Programme auf demselben Rechner, Hintergrund-Update-Dienste und bestimmter Datenverkehr innerhalb des Browsers, der den Anfragepfad der Erweiterung nicht befolgt, können weiterhin über den lokalen Ausgang laufen. Die Prüfung der Netzkonsistenz darf sich nicht auf das Erweiterungsfenster beschränken. Für eine vollständige Trennung muss man beim System-Proxy oder auf einer höheren Ebene ansetzen.

Selbsttest: erst den Ausgang prüfen, dann Leaks

Wirkungsbereich einer Browser-Proxy-Erweiterung gegenüber System-Datenverkehr sowie die Reihenfolge der Selbsttests für Ausgangs-IP, WebRTC und DNS

Der erste Schritt ist die Prüfung der Ausgangs-IP. Öffne einige Seiten, die Besucher-IP und Standort zurückgeben, und prüfe einmal in einem normalen Fenster und einmal in einem Tab, auf den deine Regeln zutreffen, und vergleiche, ob die Ergebnisse übereinstimmen. Wenn eine Regel einen Proxy vorgibt und trotzdem die lokale Adresse erscheint, greift die Regel nicht oder die Domain passt nicht. Mehrere Seiten aufzurufen deckt Fälle auf, in denen nur ein Teil der Anfragen über den Proxy läuft.

Der zweite Schritt ist die WebRTC-Prüfung. Spezielle Testseiten listen die lokalen Kandidatenadressen und die öffentlichen Kandidatenadressen auf, die der Browser erhält; erscheint unter den öffentlichen Kandidaten die echte IP statt des Proxy-Ausgangs, läuft UDP nicht über den Proxy, und Seitenskripte können deinen tatsächlichen Netzwerkstandort weiterhin ermitteln.

Der dritte Schritt ist die DNS-Prüfung. Liegt der Standort des DNS-Resolvers sehr weit vom Standort des Ausgangs entfernt, stufen manche Websites die Umgebung als auffällig ein.

Der letzte Schritt ist ein erneuter Test im Inkognito-Fenster. Viele Erweiterungen sind im Inkognito-Modus standardmäßig nicht aktiv und müssen in den Erweiterungseinstellungen manuell erlaubt werden; wer das vergisst, kommt zu völlig falschen Schlüssen.

Nach dem Test entscheiden, wie man sie einsetzt

Selbsttestergebnisse sind verlässlicher als die Beschreibung einer Erweiterung. Erst wenn echter Ausgang, Standort der DNS-Auflösung und WebRTC-Exposition zusammenpassen, entscheidet man, ob die Erweiterung weiter genutzt wird oder der Ausgang auf eine tiefere Ebene verlagert wird. In Szenarien mit mehreren parallelen Umgebungen sollte jede Umgebung einen eigenen, festen Ausgang erhalten, statt dass mehrere Maschinen einen gemeinsamen Ausgang nutzen.