Cloudflare OHTTP Gateway trennt App-Anfragen von IP-Adressen

Cloudflare OHTTP Gateway soll es Anwendungen ermöglichen, Anfragen zu empfangen, ohne die Internetadresse des Nutzers zu erfahren. Gleichzeitig bleiben die Inhalte für den Vermittler, der sie weiterleitet, unlesbar. In einer Ankündigung vom 2. Oktober 2026 beschreiben die Cloudflare-Autoren Lara Schull und Akshat Mahajan einen verwalteten Dienst, der die für Oblivious HTTP (OHTTP) erforderliche Verschlüsselung übernimmt. Dieses Protokoll trennt Informationen darüber, wer eine Verbindung herstellt, von den angefragten Inhalten.

Für Website-Betreiber und Anwendungsteams betrifft die zentrale Änderung den Betrieb: Cloudflare übernimmt die Verantwortung für die Kryptografie und die Verschlüsselungsschlüssel des Gateways, statt Kunden diese Komponente selbst betreiben zu lassen. Nach Angaben des Unternehmens läuft der Dienst im weltweiten Netzwerk von Cloudflare, wobei die Kapazität automatisch angepasst wird. Anwendungsserver können ihn unabhängig davon nutzen, ob sie ansonsten hinter Cloudflare betrieben werden.

Identität und Anfrageinhalte trennen

Eine IP-Adresse ist die Netzwerkadresse, die für Verbindungen über das Internet verwendet wird. Zusammen mit Standortinformationen und Verbindungsmerkmalen kann sie einem Dienst helfen, Aktivitäten einem Nutzer zuzuordnen. OHTTP schaltet zwischen der Anwendung des Nutzers und der empfangenden Infrastruktur ein Relay ein, also einen Vermittler, der Datenverkehr weiterleitet. Der Anwendungsserver sieht dann die Netzwerkdaten des Relays statt derjenigen des Nutzers.

Cloudflare veranschaulicht dies anhand einer Anfrage, die die IP-Adresse 128.62.37.13 und die ASN 18 des Relays zeigt. Eine Autonomous System Number (ASN) kennzeichnet ein Netzwerk im Internet. Im Beispiel befindet sich das Relay in Austin, Texas, USA; als Verbindungsdetails werden TLSv1.3 und AEAD-AES-128-GCM-SHA256 aufgeführt. Transport Layer Security (TLS) schützt Verbindungen; die Verschlüsselungskennung beschreibt die verwendeten kryptografischen Verfahren. Zusammen können solche Angaben einen TLS-Fingerabdruck bilden, ein wiedererkennbares Muster von Verbindungseinstellungen. In diesem Beispiel gehören Standort und Fingerabdruck zum Relay, nicht zum Endnutzer.

Wenn viele Nutzer dasselbe Relay verwenden, lassen sich ihre einzelnen Anfragen am Anwendungsserver anhand dieser Netzwerkdaten nicht mehr unterscheiden. Das schränkt die Möglichkeit des Servers ein, Aktivitäten über diese Angaben einer bestimmten Person zuzuordnen. Es handelt sich um eine klar umrissene Datenschutzgrenze, nicht um die Behauptung, dass sämtliche Möglichkeiten zur Identifizierung einer Person entfallen wären.

Der andere wesentliche Bestandteil ist die Verschlüsselung. Ein einfacher Weiterleitungsproxy, also ein Dienst, der Datenverkehr weiterreicht, sorgt allein noch nicht für die von OHTTP geschaffene Trennung der einsehbaren Informationen. OHTTP verwendet Hybrid Public Key Encryption (HPKE), ein Verfahren zur Verschlüsselung von Nachrichten für einen vorgesehenen Empfänger, um Anfragen und Antworten verschlüsselt zu kapseln. Das Relay sieht verschlüsselte Daten statt lesbarer Inhalte. Ein Gateway zwischen Relay und Anwendungsserver entschlüsselt eingehende Anfragen und verschlüsselt ausgehende Antworten. Die Anwendung selbst verarbeitet weiterhin gewöhnliches HTTP, das von Webdiensten verwendete Protokoll für Anfragen und Antworten.

Das Ergebnis ist ein Datenschutzmodell mit aufgeteiltem Vertrauen: Das Relay kann Netzwerkkennungen des Clients sehen, nicht aber die darin enthaltene Anfrage. Gateway und Anwendungsserver können dagegen die Anfrageinhalte sehen, ohne die Netzwerkkennungen des Nutzers zu erhalten. Antworten nehmen denselben Weg zurück. Das Gateway ist somit Teil der vertrauenswürdigen Infrastruktur, die die Anfrage lesen kann, und nicht bloß ein weiterer Weiterleitungsdienst ohne Einblick in die Inhalte.

So funktioniert das verwaltete Gateway

Cloudflare OHTTP Gateway wird für eine Zone aktiviert, also die über Cloudflare verwaltete Domainkonfiguration. Clients senden korrekt formatierte OHTTP-Anfragen an https://your-zone.com/.well-known/ohttp-gateway. Das Gateway entschlüsselt jede Anfrage, stellt eine separate Anfrage an den Anwendungsserver und verschlüsselt die Antwort, bevor es sie zurücksendet. Datenverkehr, der nicht OHTTP verwendet, durchläuft diese Gateway-Verarbeitung nicht. Eine Anwendung kann daher weiterhin auch gewöhnliche HTTP-Anfragen annehmen.

Der Dienst unterstützt Standard-OHTTP und Chunked OHTTP, bei dem Nachrichten in Teile zerlegt werden, die sich schrittweise verarbeiten lassen. Cloudflare empfiehlt die Chunked-Variante für eine bessere Leistung. Nach Darstellung des Unternehmens greift das Konzept Schwierigkeiten auf, auf die Kunden von Cloudflare OHTTP Relay beim Betrieb eigener Gateways gestoßen sind.

Die Bindung des Gateways an eine Zone begrenzt zugleich, wohin es Anfragen weiterleiten kann. Bei einer Zone namens example.com können Clients foo.example.com oder bar.example.com als Ziel verwenden, nicht aber wikipedia.com. Diese Beschränkung soll verhindern, dass unbefugte Clients das Gateway eines Kunden nutzen, um Datenverkehr an fremde Domains zu leiten.

Cloudflare verwaltet außerdem die Verschlüsselungsschlüssel. Clients benötigen eine öffentliche HPKE-Schlüsselkonfiguration, also Informationen, mit denen sie Nachrichten so verschlüsseln können, dass das Gateway sie entschlüsseln kann. Sie rufen diese Konfiguration ab, indem sie eine GET-Anfrage, die übliche Weboperation zum Abrufen einer Ressource, an /.well-known/ohttp-gateway senden. Laut Cloudflare können Clients den Datenschutz verbessern, indem sie diese Schlüssel über eine andere IP-Adresse beziehen als diejenige, über die sie das Gateway kontaktieren.

Dem Relay vertrauen, ohne beide Rollen zusammenzuführen

Da das Gateway bewusst nur wenige Informationen über den ursprünglichen Client erhält, ist es darauf angewiesen, dass das Relay Clients authentifiziert und den Datenverkehr verantwortungsvoll weiterleitet. Cloudflare Access, das Produkt des Unternehmens zur Prüfung von Zugriffsberechtigungen, wird ausgeführt, bevor Gateway-Anfragen entschlüsselt werden. Kunden können mit dessen Standardrichtlinien festlegen, welche Relays Verbindungen herstellen dürfen.

Zu den unterstützten Optionen gehören gegenseitiges TLS, bei dem beide Seiten ihre Identität mithilfe digitaler Zertifikate nachweisen; statische Dienstzugangsdaten, also feste, von Software verwendete Zugangsdaten; sowie benutzerdefinierte externe Logik, also Prüfungen durch ein anderes System. Diese Kontrollmechanismen wirken Missbrauch entgegen, ohne dass das Gateway dafür denselben Einblick in den Nutzer erhalten muss wie das Relay.

Cloudflare beschreibt außerdem eine Schutzmaßnahme dagegen, dass Kunden versehentlich beide Seiten der Datenschutzgrenze bei demselben Anbieter ansiedeln. Das Gateway verweigert die Entschlüsselung von Anfragen, die von Cloudflare Workers, der Plattform des Unternehmens zum Ausführen von Anwendungen, oder von Hosts stammen, deren Datenverkehr über Cloudflare als Proxy läuft. Damit soll nach eigenen Angaben verhindert werden, dass Cloudflare sowohl die Identitäten der Clients als auch die entschlüsselten inneren Anfragen sehen kann.

Für Unternehmen, die prüfen, wie sich diese Verantwortlichkeiten getrennt halten lassen, bietet AEU-I IT, Infrastruktur und Beratung mit Sicherheit als oberster Priorität an. Diese Leistungen sind für die Überprüfung eines datenschutzsensiblen Anwendungsdesigns relevant.

Die vorliegende Ankündigung endet mitten in einem Vergleich zwischen Cloudflare OHTTP Gateway und Cloudflare OHTTP Relay. Sie liefert daher weder vollständige Empfehlungen zur Auswahl noch die kommerziellen Konditionen. Beschrieben wird jedoch ein verwaltetes Gateway mit Schlüsselverwaltung, Relay-Authentifizierung und Beschränkungen, die die Trennung der Vertrauensbereiche bewahren sollen. Für Anwendungsverantwortliche ist diese Trennung die zentrale Anforderung, die es zu prüfen gilt, nicht nur die Frage, ob der Datenverkehr verschlüsselt ist.