- Eine technische Analyse des diesmal zum Thema gewordenen OCSP
→ Um zu prüfen, ob ein Entwicklerzertifikat gültig ist, wird beim Start einer App eine Verbindung zu Apples Server hergestellt und dies überprüft
→ Wenn keine Netzwerkverbindung möglich ist, wird die App einfach gestartet
→ Ist eine Verbindung möglich, aber der Server langsam, tritt wie dieses Mal das Problem auf, dass sich alle nicht von Apple stammenden Apps nicht öffnen
→ Es gibt die Behauptung, dass bei jedem App-Start der Hash der App an Apples Server gesendet wird [1]
→ Das Problem ist, dass dafür nicht HTTPS, sondern HTTP verwendet wird (weil man sonst wiederum eine Verbindung öffnen müsste, um das HTTPS-Zertifikat zu prüfen)
- Ein Blick ins Innere
→ Mit einem HTTP-Proxy oder Wireshark dazwischen lässt sich alles mitschneiden
→ Wenn eine App einmal ausgeführt wurde und die OCSP-Prüfung erfolgt ist, wird sie für eine bestimmte Zeit nicht erneut geprüft
→ Per GET wird eine base64-kodierte Zeichenfolge von 80 Byte übertragen
→ Dieser Wert sieht wie der Hash der App aus, ist es aber „nicht“
→ Öffnet man diese Binärinformation mit OpenSSSL, sieht man, dass tatsächlich der Name des Zertifikatsausstellers, der Schlüssel-Hash und die Seriennummer enthalten sind
→ Trotzdem bleibt der Verdacht: Wenn sich das Zertifikat je nach App unterscheidet, ist das dann nicht letztlich doch dasselbe wie ein Hashwert der App?
- Entwicklerzertifikate
→ Woher kommen diese Zertifikatsinformationen?
→ Mit codesign wurde das Zertifikat einer Mac-App extrahiert (hier Firefox)
→ Die Seriennummer stimmt mit der oben mitgeschnittenen überein
→ Zieht man anschließend das Zertifikat von Thunderbird heraus, ist auch dort die Seriennummer identisch (wie zu erwarten)
→ Das heißt: Wie in [1] behauptet, Hash-Informationen zu senden, mit denen sich jede einzelne App identifizieren lässt, ist falsch
→ Natürlich stimmt es trotzdem, dass man erkennen kann, wann auf welchem Rechner eine App „eines bestimmten Entwicklers“ ausgeführt wurde
- Zum Blockieren von OCSP
→ Mit Little Snitch oder über /etc/hosts kann man dies blockieren
→ Davon wird jedoch abgeraten, weil damit eine wichtige Sicherheitsfunktion selbst blockiert wird
- TL;DR
→ macOS sendet nicht bei jedem App-Start den Hash der App an Apple
→ macOS sendet Informationen über das Entwicklerzertifikat der von Ihnen verwendeten App, und dies wird per HTTP übertragen
→ Blockieren Sie nach Möglichkeit nicht den Zugriff auf ocsp.apple.com.
4 Kommentare
Laut der englischsprachigen Wikipedia hat Google Chrome OCSP übrigens bereits seit 2012 deaktiviert. Der Grund dafür war, dass sich „der Nutzen nur schwer erkennen lässt, während die Kosten (Verzögerungen und Datenschutzprobleme) eindeutig sind“.
https://www.imperialviolet.org/2012/02/05/crlsets.html
OCSP ist ursprünglich eine Methode, die auch Webbrowser verwenden, um etwa zu prüfen, ob SSL-Zertifikate abgelaufen sind. Da die App-Authentifizierung auf ähnliche Weise wie bei SSL-Zertifikaten erfolgt, könnte man vermuten, dass es deshalb so ist.
Ich vermute, dass dies dazu dient, auch für Mac-Apps wie unter iOS App-Analytics-Informationen zu sammeln.
Dazu lesenswerte Themen
[1] Dein Computer gehört nicht dir allein https://de.news.hada.io/topic?id=3200
[2] macOS Catalina (10.15): Durch Design ausgebremst https://de.news.hada.io/topic?id=2145