Datenschutz im Internet mit Oblivious HTTP

Anbieter von Internetservices stehen vor großen Herausforderungen, wenn es darum geht, die gegensätzlichen Interessen des Produktnutzens und der Wahrung der Privatsphäre in Einklang zu bringen. Allein durch den Erhalt von Endnutzerdaten im Rahmen des täglichen Betriebs können Anbieter von Internetservices erheblichen Compliance-Anforderungen und regulatorischen Zwängen ausgesetzt sein, die mit zunehmendem Erfolg immer schwieriger zu bewältigen sind.

Einige der bedeutendsten Marken im Internet vertrauen bei der Bereitstellung ihrer Services auf der Edge bereits auf Fastly. Und wir bieten unseren Kunden natürlich auch weiterhin neue Produkte und Technologien, die ihnen helfen, ihre Services zu skalieren und gleichzeitig die Daten ihrer Nutzer zu schützen. Wir freuen uns, das neueste Produkt in unserem Datenschutzportfolio ankündigen zu können: das Fastly OHTTP-Relay, das für ausgewählte Partner jetzt als Betaversion erhältlich ist. Das Fastly OHTTP-Relay ist Teil der Oblivious HTTP-Architektur, die es Ihnen ermöglicht, kritische Request-Daten von Endnutzern zu empfangen, ohne dabei überflüssige Metadaten zu erhalten, die Rückschlüsse auf die Identität dieser Nutzer zulassen.

HTTP wurde nicht für den Datenschutz entwickelt

Der bloße Empfang einer HTTP-Anfrage von einem Endnutzer, ohne spezielle zusätzliche Header oder identifizierende Details im Body der Anfrage, liefert von Natur aus Metadaten, die zur eindeutigen Identifizierung oder Eingrenzung der Onlineidentität auf eine tatsächliche Person verwendet werden können. Browserdetails in Headern wie User-Agent und Accept sowie Netzwerkinformationen wie AS und die IP-Adresse lassen sich so clever kombinieren, dass die Identität des Endnutzers entschlüsselt werden kann. Selbst wenn diese Anfragemetadaten nicht geloggt oder an einen Datenspeicher gesendet werden, werden sie dennoch vom Endnutzer gesendet und an den Origin-Server des Service geschickt. Dabei ist es ein Leichtes, nachträglich Logs zu erstellen. Letztendlich bitten Sie Ihre Kunden, darauf zu vertrauen, dass Sie ihre Daten sorgfältig verwalten. Dies gilt auch für Nachfolgeunternehmen oder staatliche Stellen, die Ihre gesammelten Daten übernehmen und möglicherweise nicht nach denselben Prinzipien arbeiten.

Einen bestehenden HTTP-Service datenschutzgerecht umzugestalten, ist zwar möglich, es mangelt aber in der Regel an Standardisierung und wiederholbaren Verfahren. Dies kann zusätzlichen technischen Aufwand bei der Erstellung und Pflege des Service nach sich ziehen, und es besteht die Gefahr, dass sensible Informationen versehentlich weitergegeben werden. Außerdem geraten Anbieter datenschutzfreundlicher HTTP-Services vermehrt in Zugzwang, wenn es darum geht, ihren Kunden und Branchenbeobachtern ihre Lösung zu erklären, um das nötige Vertrauen zu schaffen, dass sich die Lösung wie beabsichtigt verhält.

Ein standardisierter Mechanismus zum Senden von HTTP-Anfragen an API-Endpunkte bei gleichzeitiger Wahrung der Privatsphäre der Endnutzer kann helfen, diese Hürden zu überwinden. Bei dem neuen Oblivious HTTP-Standard handelt es sich um einen Mechanismus, der sich für eine Vielzahl von API-gesteuerten Anwendungsfällen eignet und es Ihnen ermöglicht, wiederholbare, gründlich getestete und transparente Services zu erstellen. Dieser Standard befindet sich zwar noch in der Entwicklung, ist aber schon jetzt ein vielversprechender Baustein für datenschutzfreundliche Internetservices.

Aber was genau tut OHTTP eigentlich und wie funktioniert es?

Oblivious HTTP (OHTTP) ist sowohl eine Spezifikation für die Weitergabe von Nachrichten als auch eine übergeordnete Servicearchitektur. Werden beide Eigenschaften gemeinsam genutzt, kann ein HTTP-Serviceanbieter Nachrichten von einem speziellen HTTP-Client auf einem herkömmlichen HTTP-Origin-Server empfangen, ohne dass er dabei überflüssige und unerwünschte Metadaten auf Request- und Netzwerkebene erhält. Die Doppelblindheit des OHTTP-Service ist für den Schutz von Nutzerdaten unerlässlich: Der eine Layer (das Relay) verarbeitet Metadaten zur Identifizierung des Endnutzers, während der andere (das Gateway) die Request-Daten des Endnutzers verarbeitet. Diese beiden Layer kommunizieren zwar miteinander, machen aber nicht gemeinsame Sache.

Die OHTTP-Architektur besteht aus vier Layern:

1. OHTTP-Client

Der OHTTP-Client ist ein spezieller HTTP-Client, der eine für das OHTTP-Target bestimmte HTTP-Anfrage kapselt (und verschlüsselt) und sie an das OHTTP-Relay sendet. In ihrer aktuellen Version eignen sich OHTTP-Clients für die Kommunikation mit bestimmten, vorkonfigurierten und bekannten OHTTP-Services, da der Verschlüsselungscode und die Formate der gekapselten Anfragen für einen bestimmten Service einzigartig sind und im Voraus bekannt sein müssen.

2. OHTTP-Relay

Das OHTTP-Relay ist der erste von zwei Services, die den doppelblinden Kern der OHTTP-Architektur ausmachen.

Es empfängt die gekapselte Anfrage direkt vom OHTTP-Client, zusammen mit den Standard-HTTP-Request-Headern und den dazugehörigen Informationen über die Netzwerkverbindung. Dem OHTTP-Relay sind Informationen über die Identität des Clients also von Haus aus bekannt. Diese werden allerdings entfernt, bevor die Anfrage an das OHTTP-Gateway weitergeleitet wird.

Da die gekapselte Anfrage mit einem Schlüssel verschlüsselt wird, den das OHTTP-Relay selbst nicht besitzt, weiß es nicht, welche Daten der Client an das OHTTP-Target gesendet hat.

3. OHTTP-Gateway

Das OHTTP-Gateway ist der zweite der beiden doppelblinden Services, auf denen die OHTTP-Architektur basiert.

Es empfängt die anonymisierte Version der Anfrage des Client vom OHTTP-Relay und entschlüsselt und entkapselt den inneren Teil dieser Anfrage. Anschließend leitet es die Anfrage an das OHTTP-Target weiter.

Da der äußere Teil der Anfrage anonymisiert wurde, erhält das OHTTP-Gateway keine Metadaten, die Rückschlüsse auf den Client zulassen.

4. OHTTP-Target

Das OHTTP-Target ist ein Standard-HTTP-Service, der die ursprüngliche gekapselte Anfrage des Client in einem entkapselten Format empfängt, das funktionell wie eine gewöhnliche HTTP-Anfrage aussieht. Es erhält keinerlei Informationen, die Rückschlüsse auf den Client oder den Endnutzer zulassen, abgesehen von den vom OHTTP-Relay zugelassenen HTTP-Request-Headern und den Daten, die der OHTTP-Client in die gekapselte Anfrage eingefügt hat.

Das OHTTP-Target verarbeitet diese Anfrage, indem es beispielsweise eine JSON-API-Antwort an den Client zurücksendet (ohne Informationen, die Rückschlüsse auf den Client zulassen, erhalten oder verarbeitet zu haben), die anschließend vom Gateway gekapselt und über den OHTTP-Service-Stack zurückgeleitet wird.

Wie kann ich mithilfe von Fastly OHTTP-fähige Services bereitstellen?

Es ist technisch möglich, dass der HTTP-Serviceanbieter sämtliche Layer der OHTTP-Architektur (Client, Relay, Gateway und Target) implementiert und betreibt. Diese vier Komponenten arbeiten eng zusammen, um den OHTTP-fähigen Service bereitzustellen, sodass es durchaus Sinn macht, sie gemeinsam auszuführen. Diese Art der Nutzung von OHTTP erweckt auf den ersten Blick den Anschein, als wäre das Datenschutzversprechen erfüllt. Würden die beiden doppelblinden OHTTP-Services (OHTTP-Relay und -Gateway) aber gemeinsam vom selben Anbieter betrieben, stünde die Erfüllung der Datenschutzziele von OHTTP grundlegend in Frage. Dies birgt nämlich nicht nur die Gefahr eines Vertrauensbruchs, sondern bereits der bloße Anschein eines Vertrauensbruchs ist für Services, die den Schutz personenbezogener Daten ermöglichen sollen, bedenklich. 

Während die Daten des kritischen Request-Pfads weiterhin geschützt blieben, könnte der Betreiber leicht Side-Channel-Aktivitäten durchführen, um Informationen, die nur das Relay kennt (Metadaten der Client-Anfrage und Netzwerkinformationen), mit denen zu kombinieren, die nur das Gateway kennt (Body der abgegrenzten Anfrage), und so den Datenschutz der OHTTP-Architektur effektiv zu umgehen.

Selbst die Möglichkeit eines solchen Vorgehens, ohne es tatsächlich zu implementieren, untergräbt das Vertrauen der Nutzer in den Anbieter und den OHTTP-fähigen Service. Letztendlich müssen Endnutzer darauf vertrauen können, dass die OHTTP-Spezifikation gut durchdacht ist und dass der Anbieter seine Architektur so implementiert hat, dass das Versprechen, personenbezogene Daten zu schützen, tatsächlich eingehalten wird!

Das OHTTP-Relay wird daher idealerweise nicht vom HTTP-Serviceanbieter selbst bereitgestellt, sondern von einem vertrauenswürdigen Partner, der einen guten Ruf bezüglich der Bereitstellung hochverfügbarer Services unter Verwendung einer sicheren und skalierbaren Infrastruktur genießt. Fastly ist ein idealer Partner für unsere Kunden, die datenschutzfreundliche Services entwickeln möchten, um Internetnutzern ein besseres Erlebnis zu bieten.

Das OHTTP-Relay von Fastly

Fastly hat einen OHTTP-Relay-Service ins Leben gerufen, der sich aufgrund seiner Nutzung unserer globalen Edge-Compute-Plattform leicht erweitern und schnell skalieren lässt, um alle Anforderungen Ihres Service zu erfüllen. Wir unterstützen diverse OHTTP-Anwendungsfälle wie beispielsweise Folgende:

• Mobile Apps, die in regelmäßigen Abständen Absturzberichte an einen API-Endpunkt senden – oft latenzunabhängig und mit großen Payloads.

• Webbrowser, die Client-Anfragen mithilfe einer Bad-Actor-API validieren, bevor sie die Verbindung zulassen – sehr latenzempfindlich, mit sehr kleinen Payloads.

• Anwendungsfälle, die über die OHTTP-Kernspezifikation hinausgehen, wie zum Beispiel anonymisierte Log-Übermittlung, Token-Authentifizierung und mehr.

Unser erster OHTTP-fähiger Service ist FLEDGE für Google Chrome, der von Anfang an ausschließlich das OHTTP-Relay von Fastly nutzen wird, um verhaltensorientierte Anzeigen k-anonym und ohne Drittanbieter-Cookies auszuliefern. Fastly übernimmt beim Betrieb dieses Service folgende Aufgaben:

• Empfang von OHTTP-Anfragen von Google Chrome Clients

• Durchführung bestimmter Validierungen, um sicherzustellen, dass es sich tatsächlich um OHTTP-Anfragen handelt

• Entfernung aller HTTP-Header, die nicht in der Allow-Liste enthalten sind (zunächst Content-Type, Content-Length und Host)

• Weiterleitung der Anfragen an ausdrücklich festgelegte Google Backends

• Außerdem werden Google lediglich Metriken auf Serviceebene zur Verfügung gestellt. Google hat keinerlei Zugriff auf die Konfigurationen des OHTTP-Relay-Service und kann keine Rohdaten zu den Anfragen einsehen (einschließlich Request-Logs).

Ein Blick in die Zukunft

Das Fastly OHTTP-Relay ist jetzt als Betaversion verfügbar. Wenn Sie datenschutzfreundliche Internetservices entwickeln oder dies in Erwägung ziehen, würden wir gerne mit Ihnen darüber sprechen, wie Fastly Sie bei der Entwicklung, beim Betrieb und bei der Skalierung dieser Services unterstützen kann. So können Sie sicherstellen, dass die Daten Ihrer Nutzer so gut wie möglich geschützt werden und Sie ihnen gleichzeitig die bestmöglichen Erlebnisse bieten.