Acheminer les WebSocket d'URLSession via SOCKS5 sur iOS 17+

Configurez URLSessionWebSocketTask via un proxy SOCKSv5 au niveau de la session sur iOS 17 ou ultérieur et séparez le routage du déchiffrement WSS.

Les requêtes HTTPS ordinaires d'une app iOS peuvent apparaître dans un proxy de débogage alors que son trafic WebSocket manque. Identifiez d'abord le transport WebSocket : URLSessionWebSocketTask peut utiliser une configuration de proxy au niveau de la session, tandis qu'une bibliothèque qui ouvre ses propres sockets a besoin de sa propre intégration prise en charge. Pour une connexion Network.framework brute sur iOS 17+, configurez le contexte de proxy propre à NWConnection.

Sur iOS 17 ou ultérieur, créez la session avec un proxy SOCKSv5 explicite :

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)
}

Remplacez l'adresse et le port de la documentation par l'écouteur SOCKS joignable du proxy de débogage existant. Activez cet écouteur dans l'application proxy. Son écouteur HTTP peut être sur un autre port.

Créez la webSocketTask à partir de la session renvoyée. Une tâche créée via une autre URLSession n'hérite pas de la substitution de cette session. Un tableau proxyConfigurations vide utilise les valeurs par défaut du système ; ce n'est pas une sélection explicite de route directe.

Joignabilité et messages lisibles sont deux jalons distincts

Un téléphone physique a besoin d'une adresse qui atteint l'ordinateur de débogage. Sur ce téléphone, 127.0.0.1 désigne le téléphone lui-même. Vérifiez l'interface de l'écouteur et l'accès client autorisé du proxy lorsque la connexion ne l'atteint jamais.

Une route SOCKS transporte la connexion. Lire le contenu wss exige en plus la configuration d'inspection TLS de l'outil de débogage et une confiance appropriée sur l'appareil. L'épinglage de certificats ou une implémentation TLS distincte peuvent empêcher cette inspection même lorsque le trafic atteint l'écouteur.

Cherchez l'échange WebSocket et les messages une fois la connexion établie. Ne voir qu'une requête d'interrogation d'une application Socket.IO ne prouve pas que son transport WebSocket ultérieur a emprunté la même route. Gardez cette configuration de débogage explicite dans l'environnement de développement prévu de l'app.

Articles similaires