Die Datenspur im Internet - Teil 3/4
Da ein Großteil der Kommunikation im Internet verschlüsselt ist, lässt sich ohne eine entsprechende Entschlüsselung nicht nachvollziehen, welche Dienste von Browsern und Webseiten angesprochen werden.
Die Verschlüsselung erfolgt in der Regel über Zertifikate.
Wenn ein Client eine verschlüsselte Nachricht an einen Server senden möchte, muss die Nachricht mit dem öffentlichen Schlüssel des Servers verschlüsselt werden. Um sicherzustellen, dass der öffentliche Schlüssel auch zu dem gewünschten Empfänger gehört, wird die Echtheit von einer Dritten Partei mit einer digitalen Signatur bestätigt. Diese Kombination wird Zertifikat genannt.
Um die Echtheit des Zertifikats zu bestätigen, muss wiederrum die Signatur mit einem weiteren öffentlichen Schlüssel überprüft werden. Dieser Schlüssel ist wieder mit einer Signatur bestätigt, wodurch eine Zertifikatskette entsteht. Am Ende der Kette steht ein Wurzelzertifikat, welches seinen eigenen Schlüssel bestätigt.
Die Parteien, die Zertifikate unterschreiben heißen Zertifizierungsstellen. Grundsätzlich kann jeder eine Zertifizierungsstelle betreiben und Zertifikate signieren.
Damit die Zertifikate von Browsern und Programmen angenommen werden müssen sie als vertrauenswürdig eingestuft werden. Dies wird erreicht, wenn der öffentliche Schlüssel der eigenen Zertifizierungsstelle von einer anderen vertrauenswürdigen Zertifizierungsstelle signiert wird.
Eine Möglichkeit ist es, sich selbst zu signieren und das Zertifikat dann in den Programmen oder im Betriebssystem als vertrauenswürdiges Zertifikat zu hinterlegen.
Um die verschlüsselte Kommunikation zwischen Browser und Webseite zu entschlüsseln, kann man mit dem Programm Mitmproxy einen MITM-Angriff gegen sich selbst durchführen.
„MITM“ steht hier für „man in the middle“. Das bedeutet, dass bei dem MITM-Angriff die gesamte Kommunikation über eine dritte Partei geleitet wird, die dann alle Nachrichten mitlesen und verändern kann.
Der Mitmproxy gibt sich gegenüber dem Client als echten Zielserver, und gegenüber dem Server als echten Client aus. Der Client fragt also das Zertifikat bei dem vermeintlichen Server an und bekommt ein gefälschtes Zertifikat von dem Mitmproxy zurück. Dieses gefälschte Zertifikat wird angenommen, wenn das selbst signierte Zertifikat vom Mitmproxy als vertrauenswürdig eingestuft wird.
Werden die Nachrichten vom Client mit diesem Zertifikat verschlüsselt, kann der Mitmproxy die Nachrichten entschlüsseln, lesen und verändern. Danach fragt der Mitmproxy den echten Server an und leitet die gegebenenfalls veränderte Nachricht des Clients weiter.
Da der Server den Mitmproxy für den echten Client hält, kann der Mitmproxy auch die Antwort des Servers entschlüsseln und verändern. Die gegebenfalls veränderte Antwort wird dann vom Mitmproxy wiederrum an den Client weitergeleitet.
Soweit die Theorie. Nun kommt der praktische Teil.
Ich konnte das Programm Mimproxy ohne Probleme auf meinem Rechner installieren. Leider nutzt Chrome standardmäßig nur den systemweiten Proxy, weshalb ich noch eine Erweiterung installiert habe, um den Proxy nur bei einem neu angelegten Browserprofil zu verwenden. Die Daten habe ich über das Web-Interface von Mitmproxy analysiert.
Bei dem ersten Start wird die „neuer Tab“ Seite aufgerufen und direkt automatisch ein „CONSENT“ Cookie gesetzt. Danach wird der gesetzte Cookie an ogs.google.com gesendet und es wird ein weiterer Cookie mit dem Namen „NID“ gesetzt. Außerdem werden Schriften und das Google Logo geladen.
Sobald man anfängt, etwas in die Such-/URL-Liste einzutippen, wird jeder neue Buchstabe übertragen. Dabei werden auch immer die beiden Cookies mitgeschickt. Bei dem Chrome Browser ist Google-Suche in der URL-Leiste integriert und Vorschläge werden während des Tippens angezeigt, weshalb natürlich jeder neue Buchstabe übertragen werden muss. Wenn die Einstellung „Suchanfragen und URLs automatisch vervollständigen“ ausgeschaltet wird, werden während des Tippens keine Daten vom Browser versendet.
Bei dem einfachen Aufruf von google.com wurden mehrmals GET-Anfragen an adservice.google.de und googleads.g.doubleclick.net gesendet, die mit einem Status-Code 302 beantwortet wurden. Dabei wurden Cookies zwischen den Domains ausgetauscht. Zuerst wird eine GET-Anfrage an adservice.google.de gesendet, die dann an googleads.g.doubleclick.net weitergeleitet wird. Danach werden verschiedene IDs ausgetauscht und am Ende der Kette wird ein weiterer Cookie von googleads.g.doubleclick.net gesetzt. Des Weiteren wird jedes Mal, wenn das Browserfenster mit der Seite google.com fokussiert wird, eine POST-Anfrage inklusive der gesetzten Cookies an google.com gesendet. Bei der „Neuer Tab“ Seite ist dies nicht der Fall.
Dies ist Teil 3 der 4-teiligen Betrachtung "Datenspur im Internet"