Wie Google über FireFox das Surfverhalten ausspionieren kann
FireFox macht standardmäßig von Google’s Safe Browsing API Gebrauch. Das bedeutet, dass FireFox in kurzen Abständen eine Liste mit Adressen gefährlicher Webseiten von einem Google Server abruft. Die Abstände betragen meist nicht mehr als 10 Minuten.
FireFox gleicht dann die Adresse jeder angeforderten Webseite mit der lokal gespeicherten Liste gefährlicher Webseiten ab und warnt den Benutzer, falls dieser beispielsweise auf eine Phishing-Webseite gelangen würde. Da der Abgleich mit der Blacklist lokal erfolgt, ist dies auf den ersten Blick hin unproblematisch.
Die Kommunikation mit dem Google Server kann man im HTTP traffic verfolgen, zum Beispiel mit dem FireFox Add-on HttpFox:
Ein HTTP POST Request wird an safebrowsing.clients.google.com geschickt, um die lokale Liste mit gefährlichen Webseiten zu aktualisieren. Dieser Request übermittelt unter anderem einen Parameter wrkey (wrapped key).
Der wrapped key kommt von Google und wird von FireFox einmalig mit einem GetKey Request angefordert (z.B. beim ersten Start nach der Installation von FireFox). Dafür stellt FireFox einmalig eine sichere SSL Verbindung zum Google Server sb-ssl.google.com/safebrowsing/newkey her, über die FireFox den wrapped key sowie einen client key erhält.
Unter Windows werden die beiden Schlüssel derzeit als clientkey und wrappedkey persistent in der Datei urlclassifierkey3.txt gespeichert. Zu finden ist die Datei unter Windows 7 meist in einem Unterverzeichnis von:
C:\Users\Benutzer\AppData\Roaming\Mozilla\Firefox\Profiles
Der Inhalt von urlclassifierkey3.txt sieht dann zum Beispiel wie folgt aus:
clientkey:24:GhoDWEi7rt1mnYwnInRu7J==
wrappedkey:100:ALEgNisfx_qJPmxfsu88zfuINON1683R77snhVvH-Zc6fY58W5pzUdW8zGbuFRCauxaj2OIs9aABKPkJayMllmn2byG1zkpcTg==
Google erzeugt den wrappedkey (wrkey) aus dem clientkey, indem es den clientkey mit einem privaten Schlüssel verschlüsselt. Der wrappedkey ist also die verschlüsselte Form des clientkey und kann nur von Google entschlüsselt und in den clientkey umgewandelt werden.
Der wrkey wird in dem HTTP POST Request mitgeschickt, um für den HTTP Response (die Antwort vom Server) einen MAC (Message Authentication Code) anzufordern. Der MAC dient dazu, alle Antworten vom Server vor Man-in-the-middle-Angriffen (MITM-Angriff) zu schützen. Er stellt also sicher, dass die Blacklist-Updates auch wirklich von Google kommen und nicht mit falschen Daten eines MITM kompromittiert wurden.
Der Google Server erhält den Request und wandelt den wrkey mit seinem privaten Schlüssel zurück in den clientkey um, konkateniert den clientkey mit den eigentlichen Response-Daten, erzeugt aus der Konkatenation einen 128-bit MD5 digest und schickt diesen base-64 enkodiert als MAC mit jedem Response zurück an FireFox.
FireFox kann wiederum ebenfalls aus den Response-Daten und dem clientkey den MAC berechnen und mit dem mitgeschickten MAC aus dem Response vergleichen. Sind die MACs gleich, kann den Daten vertraut werden.
Mit dem Response setzt Google ein Cookie in FireFox. Der bei Google angestellte Product Manager Ian Fette (u.a. zuständig für die Sicherheit bei Google Chrome) rechtfertigt dies in einem Bug-Tracker damit, dass Google’s anti-DoS Infrastruktur unter anderem Cookies einsetzt.
Das Cookie ist aber nur ein Problem bei der Verwendung von Google’s Safe Browsing API durch FireFox. Der wrkey ist das zweite Problem. Er ist im Prinzip nichts anderes, als eine eindeutige ID, die alle paar Minuten an Google übertragen und mit der aktuellen IP des Benutzers verknüpft wird. Der wrkey ändert sich nicht, selbst wenn die eigene IP erneuert wird.
Damit ist der wrkey ein absolutes Datenschutz-Desaster, denn Google kann von einer IP zurück auf einen wrkey und damit auf einen FireFox-Benutzer schließen. Genau genommen sogar auf ein FireFox-Profil. Wird also eine Webseite besucht, welche Dienste von Google verwendet oder nachlädt (z.B. Google+, YouTube, Gmail, google-analytics.com, google.com, etc.), dann hätte Google die Möglichkeit, die besuchte Webseite dem wrkey des jeweiligen Benutzers zuzuordnen.
Hat der Benutzer auch noch einen Google Account, können die besuchten Seiten auch gleich noch mit den dort hinterlegten persönlichen Daten verknüpft werden. Auch der Private Browsing mode von FireFox schützt davor nicht.
Es lohnt an dieser Stelle, die Diskussion der Entwickler bei Mozilla und Google zu lesen. Interessant ist dabei, wie sehr die Google-Seite versucht, die Verwendung des Cookies und des wrkeys zu rechtfertigen und zu erhalten. Da Google der Hauptgeldgeber für das FireFox-Projekt ist, dürfte diese Problematik wohl auch weiter bestehen bleiben.
Google selbst versucht natürlich, das Datenschutz-Problem herunterzuspielen und behauptet, alle Logs regelmäßig zu löschen und schon gar nicht mit persönlichen Daten zu verknüpfen. Google wird aber nicht umsonst als Datenkrake bezeichnet, die alle Dienste “kostenlos” anbietet, um so an möglichst viele Nutzerdaten zu gelangen.
Bereits die Existenz dieser Funktionalität stellt ein Problem dar, selbst wenn Google sie nicht mißbrauchen würde. Jeder, der Google durch rechtliche, behördliche oder geheimdienstliche Schritte kontrollieren kann, ist in der Lage, die Funktion für seine Zwecke einzusetzen.
Momentan gibt es zumindest in FireFox 11 nur eine Notlösung, das Abschalten des Phishing-Schutzes bzw. der Safe Browsing API Requests, indem man die zwei Häkchen in den Sicherheitseinstellungen von FireFox entfernt (ACHTUNG: auf eigene Gefahr!):
