URLSession-WebSockets via SOCKS5 routeren op iOS 17+

Configureer URLSessionWebSocketTask via een SOCKSv5-proxy op sessieniveau op iOS 17 of nieuwer en scheid het routeren van WSS-ontsleuteling.

De gewone HTTPS-verzoeken van een iOS-app kunnen in een debugproxy verschijnen terwijl het WebSocket-verkeer ontbreekt. Identificeer eerst het WebSocket-transport: URLSessionWebSocketTask kan een proxyconfiguratie op sessieniveau gebruiken, terwijl een bibliotheek die eigen sockets opent zijn eigen ondersteunde integratie nodig heeft. Voor een ruwe Network.framework-verbinding op iOS 17+ configureert u de eigen proxycontext van NWConnection.

Op iOS 17 of nieuwer maakt u de sessie met een expliciete 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)
}

Vervang het documentatieadres en de poort door de bereikbare SOCKS-listener van de bestaande debugproxy. Schakel die listener in de proxyapplicatie in. De HTTP-listener kan op een andere poort staan.

Maak de webSocketTask aan vanuit de teruggegeven sessie. Een taak die via een andere URLSession is gemaakt, erft de overschrijving van deze sessie niet. Een lege proxyConfigurations-array gebruikt de systeemstandaard; het is geen expliciete keuze voor een directe route.

Bereikbaarheid en leesbare berichten zijn aparte mijlpalen

Een fysieke telefoon heeft een adres nodig dat de debugcomputer bereikt. Op die telefoon duidt 127.0.0.1 de telefoon zelf aan. Controleer de listenerinterface en de toegestane clienttoegang van de proxy wanneer de verbinding er nooit komt.

Een SOCKS-route draagt de verbinding. Het lezen van wss-inhoud vereist bovendien de TLS-inspectie-instelling van de debugtool en passend vertrouwen op het apparaat. Certificaatpinning of een aparte TLS-implementatie kan die inspectie verhinderen, zelfs wanneer het verkeer de listener bereikt.

Zoek de WebSocket-uitwisseling en de berichten nadat de verbinding tot stand is gebracht. Alleen één pollingverzoek van een Socket.IO-applicatie zien is geen bewijs dat het latere WebSocket-transport dezelfde route gebruikte. Houd deze expliciete debugconfiguratie binnen de beoogde ontwikkelomgeving van de app.

Gerelateerde artikelen