Oblivious HTTP Gateway API für Safe Browsing
Hinweis: Diese Dokumentation befindet sich noch in der Entwicklungsphase. Es sind Verbesserungen in naher Zukunft zu erwarten.
Die Safe Browsing Oblivious HTTP Gateway API ist eine datenschutzfreundliche API, die auf dem IETF-RFC-Protokoll namens Oblivious HTTP, RFC 9458, basiert.
Überblick
Die Safe Browsing Oblivious HTTP Gateway API ist ein Google-Dienst, mit dem Clientanwendungen URLs mit den fortlaufend aktualisierten Google-Listen unsicherer Webressourcen mit zusätzlichen Datenschutzvorkehrungen vergleichen können.
Dazu wird ein schlankes Protokoll namens Oblivious HTTP oder kurz OHTTP verwendet. Dies ist ein zustandsloses Protokoll, das von Safe Browsing-Clients verwendet werden kann, um auf Google Safe Browsing V5 APIs zuzugreifen. So profitieren Sie von einem robusten Schutz und einer erhöhten Abdeckung, ohne die Privatsphäre der Nutzer zu gefährden.
HINWEIS:Der Zugriff auf Google Safe Browsing V4 APIs ist über diesen Dienst nicht möglich.
Oblivious-HTTP-Protokoll für Safe Browsing
RFC-Protokoll
Oblivious HTTP ist ein in RFC 9458 definiertes einfaches Protokoll, das zum Verschlüsseln und Senden von HTTP-Nachrichten von einem Client an einen Zielserver verwendet wird. Dabei wird ein vertrauenswürdiger Relay-Dienst auf eine Weise verwendet, bei der die Nutzung von Metadaten wie IP-Adresse und Verbindungsinformationen für die Clientidentifikation durch den Zielserver reduziert wird. So werden neben dem einfachen HTTP/S-Protokoll auch Datenschutz und Sicherheit gewährleistet. Das Protokoll verwendet zum Codieren/Decodieren von HTTP-Anfragen/-Antworten Binary HTTP (definiert in RFC 9292).
Im Prinzip steht ein Relay zwischen der Client- und Gateway-Ressource, die den Clienttraffic weiterleitet, indem alle Clientkennungen entfernt werden, einschließlich datenschutzfreundlicher Attribute wie IP-Adressen. So werden eingehende HTTP-Anfragen an den Gateway-Dienst anonymisiert. Der zusätzliche Vorteil von OHTTP besteht darin, dass alle Anfragen mit Ende-zu-Ende-Verschlüsselung geschützt sind. Das bedeutet, dass Safe Browsing-Abfragen der Clients (d. h. abgeschnittene Hashes von URL-Ausdrücken) für das Relay nicht sichtbar sind. Eine Beispielimplementierung in Chrome finden Sie in diesem Blogpost.
Clients können einen beliebigen Relay-Anbieter auswählen (z. B. Fastly), um sie in den Dienst zu integrieren. Das Relay muss die Oauth 2.0-Authentifizierung mit dem folgenden Autorisierungsbereich verwenden, um auf den Dienst zugreifen zu können.
// OAuth Authorization scope:
https://www.googleapis.com/auth/3p-relay-safe-browsing
API-Endpunkte
Öffentlicher OHTTP-Schlüssel
Dieser Endpunkt stellt die Konfiguration des öffentlichen OHTTP-Schlüssels gemäß RFC 9458 bereit, die vom Client zum Verschlüsseln von OHTTP-Anfragen verwendet wird.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
Der oben genannte API-Schlüssel ist nicht unbedingt erforderlich. Der Server ändert den öffentlichen OHTTP-Schlüssel nicht auf Grundlage des bereitgestellten API-Schlüssels. Clients können dies prüfen, indem sie andere gültige API-Schlüssel für den Zugriff auf diesen Endpunkt oder gar keine API-Schlüssel verwenden und prüfen, ob die Antwort tatsächlich denselben öffentlichen OHTTP-Schlüssel enthält. Für eine einfachere Fehlerbehebung wird jedoch ein API-Schlüssel empfohlen. Damit können Clients Statistiken wie die Anzahl der Anfragen in der Google Cloud Console ansehen. Wenn der Client einen API-Schlüssel angeben möchte, finden Sie in dieser Dokumentation Informationen zum Einrichten von API-Schlüsseln.
Wie im Abschnitt Datenschutzempfehlungen beschrieben, wird Kundenanbietern empfohlen, eine zentrale Infrastruktur für die Schlüsselverteilung einzurichten, um den Schlüssel von diesem Endpunkt abzurufen und anschließend an ihre Clientanwendungen zu verteilen, um die Ziele für die Konsistenz zu erreichen.
Gemäß der Anleitung zur Schlüsselverwaltung werden Schlüssel auf dem Server regelmäßig rotiert. Clients sollten den Schlüssel aktualisieren, d.h. die lokale Kopie des Schlüssels von Zeit zu Zeit abrufen und aktualisieren, um Entschlüsselungsfehler zu vermeiden.
Clients sollten den öffentlichen Schlüssel einmal pro Tag aktualisieren (abrufen und aktualisieren). Wenn ein zentralisierter Verteilungsmechanismus verwendet wird, sollte dieser Mechanismus dafür sorgen, dass die Schlüssel einmal pro Tag abgerufen und verteilt werden.
Gekapselte OHTTP-Anfrage
Dieser Endpunkt stellt die OHTTP-Anfrage aus, die im HTTP-Text der POST-Anfrage enthalten ist, indem er eine Anfrage entschlüsselt. Anschließend verschlüsselt er die OHTTP-Antwort, um in der HTTP-Antwort an Relay weitergeleitet zu werden. Der Client muss den Content-Type-Anfrageheader als message/ohttp-req in die HTTP-POST-Anfrage einfügen.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
HINWEIS:Gemäß den Richtlinien zu RFC müssen Sie die innere Anfrage mit dem Binary HTTP-Protokoll RFC 9292 codieren (siehe V5-Dokumentation zum Erstellen einer Safe Browsing-Anfrage).
Clientbibliotheken
Google Quiche hat clientseitige Implementierungen für OHTTP- und BHTTP-Protokolle. Es wird empfohlen, dass Clients diese Bibliotheken verwenden. Informationen zum Erstellen von OHTTP-Anfragen für den Zugriff auf die API finden Sie unten im Pseudocode.
Beispiel für clientseitige Implementierung
Clients rufen den öffentlichen Schlüssel für oblivious HTTP vom public key-Endpunkt ab. Initialisieren Sie anschließend die Konfiguration des Quiche-OHTTP-Schlüssels und initialisieren Sie den Quiche-OHTTP-Client.
auto ohttp_key_cfgs = quiche::ObliviousHttpKeyConfigs::ParseConcatenatedKeys(std::string public_key);
auto key_config = ohttp_key_cfgs->PreferredConfig();
auto public_key = ohttp_key_cfgs->GetPublicKeyForId(key_config.GetKeyId())
auto ohttp_client = quiche::ObliviousHttpClient::Create(public_key, key_config);
Der Client verwendet Binär-HTTP-Codierung, um eine BHTTP-Anfrage vor der Verschlüsselung als ersten Schritt zu erstellen.
quiche::BinaryHttpRequest::ControlData bhttp_ctrl_data{
.method = "POST",
.scheme = "https",
.authority = "safebrowsing.googleapis.com",
.path = "/v5/hashes:search?key=<API key>&hashPrefixes=<HASH prefix 1>&hashPrefixes=<HASH prefix 2>",
};
quiche::BinaryHttpRequest bhttp_request(bhttp_ctrl_data);
Der Client verschlüsselt anschließend die binäre HTTP-Anfrage, die im obigen Schritt erstellt wurde.
auto bhttp_serialized = bhttp_request.Serialize();
auto ohttp_request = ohttp_client.CreateObliviousHttpRequest(*bhttp_serialized);
// Client must include this in POST body, and add `Content-Type` header as "message/ohttp-req".
auto payload_include_in_post_body = ohttp_request.EncapsulateAndSerialize();
Sobald die Antwort von Relay eingeht, wird sie vom Client entschlüsselt. Die Antwort enthält den Content-Type-Antwortheader als ohttp-res.
auto ctx = std::move(ohttp_request).ReleaseContext();
auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);
Nachdem Sie die OHTTP-Antwort erfolgreich entschlüsselt haben, decodieren Sie die Ausgabe mit Binär-HTTP.
auto bhttp_response = BinaryHttpResponse::Create(ohttp_response.GetPlaintextData());
if (bhttp_response.status_code() == 200) {
auto http_response = bhttp_response.body();
auto response_headers = bhttp_response.GetHeaderFields();
}