SOCKS5-Authentifizierungsmethoden (RFC 1929)

SOCKS5 (definiert in RFC 1928) geht von keiner Authentifizierungsmethode aus — sie verhandelt eine. Sobald die TCP-Verbindung zum Proxy geöffnet ist, sendet der Client ein Begrüßungssignal, das die unterstützten Authentifizierungsmethoden auflistet, und der Proxy wählt eine aus.

Die Begrüßung des Clients lautet: ein Versionsbyte (0x05), eine Anzahl von Methoden, gefolgt von so vielen Methoden-Identifikatoren. Die gängigen Methoden sind 0x00 "keine Authentifizierung erforderlich", 0x02 "Benutzername/Passwort" und 0xFF "keine akzeptablen Methoden". Der Server antwortet mit zwei Bytes: der Version und der einzelnen Methode, die er gewählt hat. Wenn er 0x00 zurückgibt, verbinden Sie sich sofort; wenn er 0x02 zurückgibt, muss der Client nun die Unterverhandlung für Benutzername/Passwort durchführen, bevor er eine Verbindungsanfrage stellen kann. Wenn der Server 0xFF zurückgibt, war keine der angebotenen Methoden akzeptabel und er schließt die Verbindung. Deshalb erwartet ein authentifizierter s4m SOCKS5-Proxy an Port 1080, dass Ihr Client die Methode 0x02 anbietet.

Die Benutzername/Passwort-Methode (0x02) ist separat in RFC 1929 festgelegt. Es handelt sich um einen kleinen, eigenständigen Austausch, der nach der Methodenverhandlung und vor der SOCKS-Anfrage stattfindet:

• Der Client sendet: ein Sub-Verhandlungsversionsbyte (0x01 — beachten Sie, dass dies die Authentifizierungsversion und nicht die SOCKS-Version ist), eine einbyteige Benutzerlängenangabe, den Benutzernamen, eine einbyteige Passwortlängenangabe und das Passwort.
• Der Server antwortet mit zwei Bytes: der Version (0x01) und einem Statusbyte. 0x00 bedeutet Erfolg; alles andere bedeutet Misserfolg, und der Server schließt die Verbindung.

Nur nach einem Erfolgsstatus fährt der Client mit der tatsächlichen SOCKS5 CONNECT-Anfrage fort, die das Ziel benennt. Da sowohl Benutzername als auch Passwort längenpräfixierte Einzelbytes sind, ist jedes auf 255 Bytes begrenzt. Siehe unseren Proxy-Authentifizierungsleitfaden, wie sich dies mit echten Clients und der API für die Handhabung von Anmeldeinformationen auswirkt.

Der kritische ehrliche Punkt: RFC 1929 überträgt den Benutzernamen und das Passwort in Klartext. Die Bytes sind nicht verschlüsselt oder gehasht — jeder, der die TCP-Verbindung zwischen Ihnen und dem Proxy beobachten kann, kann Ihre Anmeldeinformationen lesen. Das RFC selbst erkennt dies an und warnt, dass die Methode nur dort geeignet ist, wo diese Exposition akzeptabel ist.

Was das in der Praxis bedeutet: Die Sicherheit der SOCKS5-Benutzername/Passwort-Authentifizierung hängt davon ab, dass der Weg zum Proxy vertrauenswürdig ist oder dass die gesamte SOCKS-Verbindung in etwas Verschlüsseltem eingewickelt ist. Maßnahmen, die Menschen verwenden, umfassen das Tunneln von SOCKS5 über TLS oder SSH, den Betrieb des Proxys über ein vertrauenswürdiges Netzwerk oder das Verlassen auf IP-Whitelisting anstelle von (oder zusätzlich zu) Anmeldeinformationen — was ein dedizierte IP praktikabel macht. Andere SOCKS5-Authentifizierungsmethoden existieren prinzipiell (zum Beispiel GSS-API aus RFC 1928), aber Benutzername/Passwort bleibt bei weitem die am weitesten implementierte, sodass es wichtig ist, die Klartextnatur zu verstehen — und ein wichtiges Passwort nicht als Proxy-Anmeldeinformation wiederzuverwenden.