Am 27. Juli 2026 veröffentlichte das Cloudflare Research-Team den pvcli – einen Konsolenclient für private Netzwerkprotokolle. Äußerlich ähnelt es „curl für OHTTP“: der gleiche Befehlstil, aber anstelle einer normalen Anfrage sammelt das Tool einen dreiseitigen verschlüsselten Austausch, bei dem der empfangende Server Ihre IP nicht sieht und der Zwischenknoten den Inhalt der Anfrage nicht sieht. Der Code steht unter Apache 2.0, und es sind Pläne zur Unterstützung von MASQUE und Privacy Pass vorhanden.
Für die Proxy-Industrie ist dies nicht „noch eine Veröffentlichung auf GitHub“. Es ist der erste benutzerfreundliche Weg, um den Protokollstapel zu erkunden, den Apple, Google, Mozilla und Meta seit mehreren Jahren still einführen – und der regelmäßig als „Ersatz für Proxys“ präsentiert wird. Lassen Sie uns untersuchen, was dort tatsächlich ist, und ehrlich die zentrale Frage beantworten: Deckt dieser Stapel die Aufgaben ab, wegen denen Menschen Wohn- und Mobilproxys kaufen? Spoiler: Nein, und der Grund ist architektonisch und nicht „wir sind noch nicht bereit“.
Was genau wurde eröffnet: pvcli im Detail
pvcli ist in Rust geschrieben und wird mit einem Befehl über cargo install --git installiert. Laut README ist es ein HTTP/2- und HTTP/3-Client mit Unterstützung für GET und POST, TLS 1.3 und HPKE-Verschlüsselung (RFC 9180). Der Hauptmodus ist Oblivious HTTP: Der Client gibt den ersten Hop (Relay) und das Gateway an, und das Tool führt selbst die gesamte Kryptografie und Verpackung in binary HTTP durch.
- Normale Anfrage:
pvcli https://example.com/cdn-cgi/trace, mit dem Flag--http3– über QUIC. - OHTTP-Modus:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Klassisches Proxieren:
pvcli -x https://proxy.example.com https://target.example.com– das heißt, HTTP CONNECT ist nicht verschwunden.
Die Autoren warnen ehrlich: Die Software ist experimentell und hat kein Audit durchlaufen, post-quanten HPKE wird derzeit nicht unterstützt, und einige Spezifikationen sind noch nicht einmal RFC geworden. Dies ist ein Debugging-Tool und kein fertiges Produkt für die Produktion. Und genau deshalb ist es interessant: Früher konnte man eine fremde OHTTP-Integration nur mit eigenem Code in Swift oder Rust überprüfen.
Oblivious HTTP: teile und herrsche nicht
OHTTP wurde am 12. Januar 2024 als RFC 9458 standardisiert. Die Idee ist bis zur Eleganz einfach: das Wissen darüber, „wer Sie sind“ und „was Sie anfordern“, zwischen zwei unabhängigen Teilnehmern zu trennen.
- Der Client verschlüsselt die Anfrage mit einem ephemeral Schlüssel auf dem öffentlichen Schlüssel des Gateways – für jede Anfrage wird ein neues Schlüsselpaar generiert.
- Relay (oblivious relay) sieht Ihre IP-Adresse, erhält jedoch den Chiffretext: Er kann physisch nicht lesen, wohin und worum Sie fragen.
- Gateway entschlüsselt die Anfrage und leitet sie an den Origin weiter, sieht jedoch die IP des Relays und nicht Ihre.
Die zentrale Garantie ist unlinkability: Der Origin kann zwei Ihrer Anfragen nicht miteinander verknüpfen. Die zentrale Einschränkung ist das Vertrauen: Wenn Relay und Gateway sich absprechen oder bei einem Betreiber sind, bricht die gesamte Privatsphäre zusammen. Die NCC Group hat in Audits auch praktische Schwierigkeiten hervorgehoben – Schlüsselrotation, Rate Limiting und Zugangsberechtigungen für Netzwerkverzögerungen.
In der Produktion funktioniert das Protokoll bereits, und die Liste ist beeindruckend:
- Apple – Private Cloud Compute für Anfragen an Apple Intelligence und Enhanced Visual Search in „Fotos“; die Unterstützung von OHTTP in Swift wurde im August 2024 eingeführt.
- Google – Privacy Sandbox, k-Anonymität und URL-Überprüfung in Safe Browsing ohne Offenlegung der IP; als Relay fungiert Fastly.
- Mozilla – Sammlung von Leistungsmetriken für Firefox ohne Identifizierung des Benutzers.
- Meta – Private Processing für Meta AI in WhatsApp (2025), ebenfalls über das Relay Fastly.
- Flo – „anonymer Modus“ des Zyklus-Trackers auf Basis des Cloudflare Privacy Gateway seit 2022.
Gateways, neben Cloudflare und Fastly, werden von der Internet Security Research Group im Dienst Divvi Up betrieben. Das heißt, die Infrastruktur ist real und nicht nur auf dem Papier.
MASQUE: das sieht schon nach Proxy aus
Der zweite Teil des Stacks, den Cloudflare verspricht, in pvcli hinzuzufügen, ist MASQUE. Dies ist eine Familie von Protokollen der IETF-Arbeitsgruppe, die das Proxieren in HTTP integriert:
- RFC 9298 (August 2022), CONNECT-UDP – Proxieren von UDP innerhalb von HTTP; der Client sendet ein erweitertes CONNECT mit
:protocol: connect-udp, und der Proxy verpackt QUIC DATAGRAM-Frames in UDP-Pakete. - RFC 9484 (Oktober 2023), CONNECT-IP – bereits eine vollständige IP-Ebene: rohe IP-Pakete werden in HTTP-Datagramme verpackt, und der HTTP/3-Server wird zu einem VPN-Gateway, das gleichzeitig TCP, UDP und ICMP beherrscht.
Beide Spezifikationen erfordern einen Fallback auf HTTP/2, wo QUIC und UDP auf Netzwerkebene blockiert sind – was regelmäßig in Unternehmens- und Provider-Netzen passiert. Im Wesentlichen ist MASQUE das, auf dem moderne „private Relays“ auf Betriebssystemebene basieren, bei denen der Datenverkehr zwei unabhängige Hops durchläuft: der erste kennt Sie, weiß aber nicht, wer der Empfänger ist, der zweite umgekehrt.
Privacy Pass: anonymer Pass statt Captcha
Der dritte Baustein ist der Privacy Pass, der durch drei Dokumente standardisiert wurde: RFC 9576 (Architektur), RFC 9577 (HTTP-Authentifizierungsschema) und RFC 9578 (Token-Ausgabeprotokolle, privat und öffentlich verifizierbar). Die Logik besteht aus zwei Schritten: issuance – Sie beweisen einmal, dass Sie ein Mensch oder ein vertrauenswürdiger Kunde sind, und erhalten ein Bündel blind signierter Token; redemption – Sie legen den Token der Website vor, und sie lässt Sie ohne Captcha passieren, ohne die Möglichkeit, den Token mit dem Ausstellungszeitpunkt zu verknüpfen.
Das ist genau der Mechanismus, der hinter der Idee steht, „guten Bots einen legalen Zugang zu gewähren“ – er liegt auch der Idee von signierten Agenten und Web Bot Auth zugrunde. Der Trend ist derselbe: die Trennung der Netzwerkidentität (IP) und der Zugriffsrechte (Token, Signatur).
Wird das Proxys ersetzen? Analyse ohne Illusionen
Jedes Mal, wenn eine Nachricht aus diesem Stapel veröffentlicht wird, taucht die These auf: „Warum jetzt Proxys, wenn es OHTTP gibt“. Das Problem ist, dass private Protokolle und Proxys unterschiedliche Aufgaben lösen, und der Austausch des einen gegen den anderen scheitert an vier Punkten.
1. OHTTP funktioniert nur dort, wo die Website es selbst implementiert hat
Es ist kein Overlay über das Internet, sondern ein Opt-in vom Empfänger: das Gateway wird vom Origin (oder dessen Auftragnehmer) selbst eingerichtet und konfiguriert. Man kann nicht „über OHTTP“ auf einen beliebigen Marktplatz oder ein soziales Netzwerk zugreifen – dort gibt es einfach kein Gateway. Alle genannten Implementierungen sind Unternehmen, die die IP ihrer eigenen Benutzer vor ihren eigenen Backends verbergen. Für das Sammeln von Daten von einer Drittanbieter-Website ist der Mechanismus grundsätzlich nicht anwendbar.
2. Der Ausgangspunkt ist das Rechenzentrum, und alle wissen das
Selbst wenn es ein Gateway gibt, verlässt die Anfrage die Cloudflare-, Fastly- oder ISRG-Adresse nach außen. Dies sind bekannte ASN von Hosting-Anbietern mit öffentlichen Bereichen. Antibot-Systeme bewerten IPs nach Netzwerktyp, und die Adresse des Cloud-Relays erhält genau dieselbe Bewertung wie jede andere Rechenzentrumsadresse. Sie haben Privatsphäre vom Origin erhalten, aber „wie ein gewöhnlicher Heimbenutzer auszusehen“ – das nicht. Dafür sind residential Proxys mit echten Adressen von Anbietern und mobile Pools von Betreiber-CGNAT-Netzen verantwortlich.
3. Keine Geografie, Rotation und sticky Sessions
Die Proxy-Infrastruktur bietet das, was private Protokolle designbedingt nicht haben: die Auswahl des Landes, der Region und des Anbieters, verwaltete IP-Rotation, sticky Sessions für die benötigte Anzahl von Minuten, verschiedene Pools für verschiedene Konten. OHTTP gibt Ihnen nicht die Möglichkeit zu wählen, „aus Deutschland, aus dem Netzwerk eines bestimmten ISP herauszukommen“ – es gibt überhaupt kein Konzept eines Ausgangspunkts, der Ihnen zur Verfügung steht. Für die Überprüfung lokaler Angebote, Preise nach Regionen oder die Arbeit mit geo-beschränkten Inhalten ist dies ein unüberwindbarer Unterschied.
4. Das Vertrauensmodell ist anders
OHTTP schützt vor der Verknüpfung von Anfragen mit einem bestimmten Origin, vorausgesetzt, Relay und Gateway sind unabhängig. Proxys schützen davor, dass die Website Ihre echte Adresse und Ihr Netzwerkprofil sieht. Das erste betrifft die Privatsphäre der Telemetrie und der Benutzeranfragen, das zweite den Zugang und die Lastverteilung. Die Aufgaben überschneiden sich nur teilweise, und ein „Umzug“ von einem zum anderen ist unmöglich.
Was davon in der Praxis wirklich nützlich ist
- Wenn Sie ein Produktentwickler sind, der Telemetrie oder Anfragen an seine API sendet – OHTTP über Privacy Gateway oder Divvi Up reduziert tatsächlich die Menge an gesammelten personenbezogenen Daten und vereinfacht das Gespräch mit Juristen. pvcli ermöglicht es jetzt, dies ohne das Schreiben eines Clients von Grund auf zu debuggen.
- Wenn Sie öffentliche Daten sammeln – der Stack ändert nichts: Der Ausgangspunkt und dessen Ruf bleiben Ihre Aufgabe. Für das massenhafte Parsen bleibt die funktionierende Kombination – Rechenzentrums-Proxys mit Rotation auf loyalen Plattformen und residential Proxys dort, wo ernsthafte Antibots aktiviert sind.
- Wenn Sie mit mehreren Konten arbeiten – private Protokolle lösen das Problem der Isolation nicht: Sessions auf Plattformen sind nicht nur über IP, sondern auch über Browser-Fingerabdrücke und Verhalten miteinander verbunden. Der Unterschied zwischen der IP-Ebene und der Identitätsebene wird im Material über die Unterschiede zwischen Proxys und VPNs behandelt.
- Wenn Sie den Zugang „legal“ automatisieren – hier sollten Sie genau hinsehen. Privacy Pass und signierte Agenten gehen auf ein Modell zu, bei dem Bots Zugang auf Grundlage des vorgelegten Tokens erhalten, nicht aufgrund der „Ähnlichkeit mit einem Menschen“. Dies ist der vielversprechendste Teil der Nachricht.
Fazit
Die Einführung von pvcli ist ein guter Indikator für die Reife: Private Protokolle haben die Phase der Forschungs-Preprints verlassen und verfügen über Debugging-Tools. OHTTP, MASQUE und Privacy Pass verändern tatsächlich, wie das Internet mit der Adresse des Clients umgeht, und in ein paar Jahren wird „die Website sieht Ihre IP“ nicht mehr als Axiom für den Benutzerverkehr gelten.
Aber für diejenigen, die Daten sammeln, mehrere Konten verwalten oder die Ausgabe nach Regionen überprüfen, bleibt alles beim Alten. Private Protokolle verstecken Sie vor dem, zu dem Sie auf Einladung gekommen sind. Proxys sind dort notwendig, wo keine Einladungen vergeben werden – und dort entscheiden nach wie vor der Netzwerktyp, der Ruf der Adresse und die Qualität des Pools. Es ist sinnvoll, Privacy Pass als zukünftigen legalen Kanal für Bots im Auge zu behalten und gleichzeitig eine normale Proxy-Infrastruktur für das echte Geschäft aufrechtzuerhalten.
```