URLSession-WebSockets über SOCKS5 unter iOS 17+ leiten

Konfigurieren Sie URLSessionWebSocketTask über einen SOCKSv5-Proxy auf Sitzungsebene unter iOS 17 oder neuer und trennen Sie das Routing von der WSS-Entschlüsselung.

Die gewöhnlichen HTTPS-Anfragen einer iOS-App können in einem Debugging-Proxy erscheinen, während ihr WebSocket-Verkehr fehlt. Bestimmen Sie zuerst den WebSocket-Transport: URLSessionWebSocketTask kann eine Proxy-Konfiguration auf Sitzungsebene nutzen, während eine Bibliothek, die eigene Sockets öffnet, ihre eigene unterstützte Integration benötigt. Für eine rohe Network.framework-Verbindung unter iOS 17+ konfigurieren Sie den eigenen Proxy-Kontext von NWConnection.

Unter iOS 17 oder neuer erstellen Sie die Sitzung mit einem expliziten SOCKSv5-Proxy:

import Foundation
import Network

@available(iOS 17.0, *)
func makeDebugSession() -> URLSession {
    let configuration = URLSessionConfiguration.default
    let endpoint = NWEndpoint.hostPort(
        host: "192.0.2.10", port: 8889)
    configuration.proxyConfigurations = [
        ProxyConfiguration(socksv5Proxy: endpoint)
    ]
    return URLSession(configuration: configuration)
}

Ersetzen Sie die Dokumentationsadresse und den Port durch den erreichbaren SOCKS-Listener des vorhandenen Debugging-Proxys. Aktivieren Sie diesen Listener in der Proxy-Anwendung. Ihr HTTP-Listener kann auf einem anderen Port liegen.

Erstellen Sie die webSocketTask aus der zurückgegebenen Sitzung. Eine über eine andere URLSession erstellte Aufgabe erbt die Überschreibung dieser Sitzung nicht. Ein leeres proxyConfigurations-Array verwendet die Systemvorgaben; es ist keine ausdrückliche Wahl einer direkten Route.

Erreichbarkeit und lesbare Nachrichten sind getrennte Meilensteine

Ein physisches Telefon braucht eine Adresse, die den Debugging-Rechner erreicht. Auf diesem Telefon bezeichnet 127.0.0.1 das Telefon selbst. Prüfen Sie die Listener-Schnittstelle und den erlaubten Client-Zugriff des Proxys, wenn die Verbindung ihn nie erreicht.

Eine SOCKS-Route trägt die Verbindung. Das Lesen von wss-Inhalten erfordert zusätzlich die TLS-Inspektions-Einrichtung des Debugging-Werkzeugs und passendes Vertrauen auf dem Gerät. Zertifikats-Pinning oder eine separate TLS-Implementierung können diese Inspektion verhindern, selbst wenn der Verkehr den Listener erreicht.

Suchen Sie den WebSocket-Austausch und die Nachrichten, nachdem die Verbindung hergestellt ist. Nur eine Polling-Anfrage einer Socket.IO-Anwendung zu sehen, ist kein Beweis dafür, dass ihr späterer WebSocket-Transport dieselbe Route nutzte. Halten Sie diese ausdrückliche Debugging-Konfiguration innerhalb der vorgesehenen Entwicklungsumgebung der App.

Ähnliche Artikel