Die Authentifizierung erfolgt bei SOCKS5 nicht über einen Header wie beim HTTP-Proxy, sondern über eine eigene Unterverhandlung . Dieser Unterschied erklärt auch, warum die Fehlermeldungen so nichtssagend sind: Wird die falsche Methode angeboten, liefert der Server keinen erklärenden Text, sondern sendet ein einzelnes Byte und schließt die Verbindung.
Methodenverhandlung
Jeder Schritt umfasst nur wenige Bytes in eine Richtung. Schlägt die Verhandlung fehl, gibt der Server 0xFF oder 0x01 0x01 zurück und schließt die Verbindung – einen erklärenden Fehlertext gibt es nicht.
Unterstützte Methoden
| Code | Methode | Nutzung |
|---|---|---|
0x00 | Keine Authentifizierung erforderlich | Über IP-Whitelist geschützte Server |
0x01 | GSSAPI | Unternehmensumgebungen mit Kerberos (selten) |
0x02 | Benutzername / Passwort | Die gängigste kommerzielle Methode |
0xFF | Keine akzeptable Methode | Ablehnende Antwort des Servers |
Benutzername und Passwort werden im Klartext übertragen. SOCKS5 selbst bietet keine Verschlüsselung. Wenn Sie es in einem nicht vertrauenswürdigen Netz einsetzen, können Ihre Zugangsdaten mitgelesen werden; in diesem Szenario ist der Betrieb über einen SSH-Tunnel sicherer.
Haeufige Probleme
Die Browser-Zeile ist besonders wichtig: Viele Browser unterstützen die SOCKS5-Authentifizierung nicht über die Oberfläche. In diesem Fall wird eine lokale Bridge benötigt, welche die Zugangsdaten überträgt.
Das Browser-Problem und seine Lösung
Chrome und Firefox unterstützen die SOCKS5-Authentifizierung nur eingeschränkt oder gar nicht. Es gibt zwei praktikable Lösungen:
Auf IP-Whitelist umsteigen
Sofern der Anbieter das unterstützt, ist dies die sauberste Lösung: Es werden überhaupt keine Zugangsdaten übertragen und der Browser funktioniert problemlos.
Lokale Bridge einrichten
Betreiben Sie auf dem Rechner einen kleinen Proxy, der die Zugangsdaten überträgt, und tragen Sie diesen 127.0.0.1 im Browser ein. Die Methode haben wir in unserem Beitrag zum Chaining erklärt.
Konfiguration je nach Bibliothek
Wenn Ihr Passwort @, : oder / enthält, verwenden Sie statt des URL-Formats das separate Feld; andernfalls müssen Sie eine Prozentkodierung vornehmen.
Vergleich mit der Whitelist
Auch bei SOCKS5 gelten die beiden Modelle, und die Auswahlkriterien sind dieselben wie beim HTTP-Proxy. Für einen ausführlichen Vergleich können Sie unseren Beitrag zu den Authentifizierungsmethoden nachlesen. Der einzige SOCKS5-spezifische Unterschied ist das Problem der Browser-Unterstützung: Die Whitelist beseitigt es vollständig.
Überprüfung
Ein bewusster Test mit falschem Passwort hilft Ihnen, die Fehlermeldung wiederzuerkennen, wenn tatsächlich ein Problem auftritt.
Zusammenfassung
Die SOCKS5-Authentifizierung erfolgt über eine eigene Unterverhandlung, und die Fehlermeldungen sind wenig aussagekräftig. Die beiden häufigsten Probleme sind, dass der Client die Authentifizierungsmethode gar nicht anbietet und dass Browser diese Methode nicht unterstützen. Da die Zugangsdaten im Klartext übertragen werden, ist in nicht vertrauenswürdigen Netzen Vorsicht geboten. Die Whitelist ist die sauberste Lösung, die sowohl das Browser-Problem als auch das Risiko eines Lecks beseitigt. Um Ihre Adressen zu testen, unser Proxy-Prüfwerkzeug können Sie nutzen.