Folgendes Problem: eine externe Agentur entwickelt im Auftrag eine iOS-App, um darüber via API auf die eigene Website zuzugreifen. (Der Klassiker — der 250. RSS Reader, aber immer wieder gern genommen.)
Es kommt, wie es kommen muss: Irgendetwas funktioniert nicht, wie man sich das gedacht hat. Die Agentur sagt, der Webserver liefert das Falsche, der Webmaster schaut ins Logfile und sagt, da kommt erst gar nicht der richtige Request an. Was tun?
Erster Schritt: ein Hub und Wireshark
Bis vor kurzem habe ich dann immer zu einem betagten Hub gegriffen, diesen zwischen WLAN-Router und Internet-Gateway gestellt. An diesen habe ich dann an einen weiteren Port einen “echten” Rechner angeschlossen und via Wireshark den Netzwerkverkehr mitgeschnitten und analysiert.
Dabei entstehen ein paar Probleme:
- Wer hat immer einen Hub griffbereit? Solche prähistorischen Geräte hüte ich zwar wie meinen Augapfel (man weiß nie, wann man sie mal wieder gebrauchen kann), aber in der Regel hat man doch keines zur Hand.
- Die nächste Stufe wäre dann ein managebarer Switch, dem man einen Monitoring Port konfigurieren kann.
- Es ist nicht jedermanns Sache, den Netzwerkverkehr auf Höhe der Grasnarbe zu analysieren.
mitmproxy
Solange es sich um http/https Verkehr handelt, kann man einen anderen Weg beschreiten. Man lässt einen Proxy-Server laufen, der die Netzwerkdaten ausgibt.
Ein solcher Proxy ist zum Beispiel mitmproxy. mitm steht hierbei für man in the middle.
Die Installation unter Mac OS X 10.6 läuft recht einfach ab:
git clone git://github.com/cortesi/mitmproxy.git
In das nun entstandene Verzeichnis kopiert man nun noch von http://excess.org/urwid/ das innere urwid Verzeichnis, sodass das Verzeichnis wie folgt aussieht:
Nun kann man bereits den Proxy starten:
./mitmproxy -p 8080
Auf dem iOS Gerät selbst stellt man nun den Rechner als Proxy ein. Wichtig ist dabei, dass das iOS Gerät den Rechner “sehen” kann, sie also zum Beispiel im selben WLAN sind.
Via
ifconfig
kann man auf dem Rechner die eigene IP-Adresse ermitteln.
Unter Einstellungen-> WLAN -> eigene SSID lässt sich unten der HTTP-Proxy einstellen. Hier trägt man nun die IP-Adresse des Rechners unter Server ein und 8080 den Port.
Der Aufruf von Google sieht dann beispielsweise so aus:
Über die Return-Taste lassen sich nun Requests genauer anschauen:
(Mit der q-Taste kommt man wieder zurück. Mit der tab-Taste kann man sich den Response-Body genau ansehen.)
SSL-Verschlüsselung
Soweit so gut. Doch was macht man, wenn die App via SSL/https mit dem Webserver spricht? Kein Problem:
Der mitmproxy erzeugt beim ersten Starten unter ~/.mitmproxy ein SSL-Zertifikat, das man nun dem iOS Gerät als vertrauenswürdig geben muss.
Das macht man so: Man schickt sich die Datei mitmproxy-ca-cert.pem. Diese öffnet man dann auf dem iOS Gerät und bestätigt, dass man diesem Zertifikat trauen will.
Schon kann man sämtlichen https-Verkehr einsehen.
Dies funktioniert natürlich nur soweit, wie die App auf die globalen http-Einstellungen für Proxies zurückgreift und nicht selbständig Zertifikate überprüft. Da man als Entwickler aber am liebsten auf bereits gelöste Probleme zurückgreift, dürften die meisten iOS-Apps den internen Safari für http(s)-Anfragen nutzen.
Recent Comments