Safe Browsing Oblivious HTTP Gateway API
Hinweis: Diese Dokumentation befindet sich noch in der Entwicklungsphase. Verbesserungen sind schon 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, aufbaut.
Übersicht
Die Safe Browsing Oblivious HTTP Gateway API ist ein Google-Dienst, mit dem Client-Anwendungen URLs mit den fortlaufend aktualisierten Google-Listen unsicherer Webressourcen abgleichen können, wobei zusätzliche Datenschutzmaßnahmen implementiert sind.
Dazu wird ein einfaches Protokoll namens Oblivious HTTP, kurz OHTTP, verwendet. Dies ist ein zustandsloses Protokoll, das von Safe Browsing-Clients verwendet werden kann, um auf Google Safe Browsing V5 APIs zuzugreifen, um robuste Schutzmaßnahmen und eine erhöhte Abdeckung zu erhalten, ohne die Nutzer zu gefährden. Datenschutz.
HINWEIS: Über diesen Dienst kann nicht auf Google Safe Browsing V4 APIs zugegriffen werden.
Safe Browsing – Oblivious HTTP-Protokoll
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, die die Verwendung von Metadaten wie IP-Adresse und Verbindungsinformationen durch den Zielserver zur Client-Identifizierung verringert und neben dem einfachen HTTP/S-Protokoll Datenschutz und Sicherheit bietet. Das Protokoll verwendet binäres HTTP (in RFC 9292 definiert), um HTTP-Anfragen/-Antworten zu codieren/decodieren.
Allgemein steht ein Relay zwischen der Client- und Gateway-Ressource, die den Clienttraffic weiterleitet. Dazu werden alle Clientkennungen entfernt, einschließlich datenschutzsensibler Attribute wie IP-Adressen, wodurch eingehende HTTP-Anfragen an den Gateway-Dienst effektiv anonymisiert werden. Der zusätzliche Vorteil von OHTTP ist, dass alle Anfragen Ende-zu-Ende-verschlüsselt sind. Das bedeutet, dass die Safe Browsing-Abfragen (d.h. abgeschnittene Hashes von URL-Ausdrücken) sind für das Relay nicht sichtbar. blogpost finden Sie ein Beispiel für eine Implementierung in Chrome.
Kunden können einen beliebigen Relay-Anbieter auswählen (z. B. Fastly) in den Dienst integriert werden. 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 eine Konfiguration für öffentlichen OHTTP-Schlüssel gemäß RFC 9458 bereit, die vom Client zum Verschlüsseln der OHTTP-Anfrage verwendet wird.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
Der obige API-Schlüssel ist nicht unbedingt erforderlich. Der Server variiert den öffentlichen OHTTP-Schlüssel nicht basierend auf dem bereitgestellten API-Schlüssel. Clients können dies überprüfen, indem sie verschiedene gültige API-Schlüssel für den Zugriff auf diesen Endpunkt verwenden oder vollständig keine API-Schlüssel verwenden und prüfen, ob die Antwort tatsächlich denselben öffentlichen OHTTP-Schlüssel enthält. Zur Vereinfachung der Fehlerbehebung wird jedoch ein API-Schlüssel empfohlen. So können sich Clients Statistiken wie die Anzahl der Anfragen in der Google Cloud Console ansehen. Wenn der Client einen API-Schlüssel bereitstellen möchte, finden Sie in dieser Dokumentation Informationen zum Einrichten von API-Schlüsseln.
Wie im Abschnitt Datenschutzempfehlungen beschrieben, wird den Kundenanbietern empfohlen, eine zentrale Infrastruktur für die Schlüsselverteilung einzurichten, um die Ziele für Schlüsselkonsistenz zu erreichen. So kann der Schlüssel von diesem Endpunkt abgerufen und anschließend an ihre Clientanwendungen verteilt werden.
Gemäß der Anleitung zur Schlüsselverwaltung werden die Schlüssel regelmäßig auf dem Server rotiert. Clients sollten den Schlüssel aktualisieren, d.h. die lokale Kopie des Schlüssels in regelmäßigen Abständen abrufen und aktualisieren, um Entschlüsselungsfehler zu vermeiden.
Clients sollten den öffentlichen Schlüssel einmal täglich aktualisieren (abrufen und aktualisieren). Wenn ein zentraler Verteilungsmechanismus verwendet wird, sollte mit diesem Mechanismus sichergestellt werden, dass die Schlüssel einmal pro Tag abgerufen und verteilt werden.
Gekapselte OHTTP-Anfrage
Dieser Endpunkt verarbeitet die OHTTP-Anfrage, die im HTTP-Text der POST-Anfrage enthalten ist, indem er die Anfrage entschlüsselt und anschließend die OHTTP-Antwort verschlüsselt, damit sie in der HTTP-Antwort an Relay zurückgesendet wird. Der Client muss den Anfrageheader Content-Type als message/ohttp-req in die HTTP-POST-Anfrage aufnehmen.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
HINWEIS: Codieren Sie die innere Anfrage gemäß den RFC-Richtlinien mit dem Binär-HTTP-Protokoll RFC 9292. Informationen zum Erstellen einer Safe Browsing-Anfrage finden Sie in der V5-Dokumentation.
Clientbibliotheken
Google Quiche bietet clientseitige Implementierungen für OHTTP- und BHTTP-Protokolle. Es wird empfohlen, für Clients diese Bibliotheken zu verwenden. Unten finden Sie den Pseudocode zum Erstellen von OHTTP-Anfragen für den Zugriff auf die API.
Beispiel für eine clientseitige Implementierung
Clients rufen den öffentlichen HTTP-Schlüssel von Oblivious HTTP vom Endpunkt des öffentlichen Schlüssels ab. Initialisieren Sie anschließend die OHTTP-Schlüsselkonfiguration für die Quiche und dann den OHTTP-Client für die Quiche.
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 als ersten Schritt vor der Verschlüsselung die HTTP-Binärcodierung, um die BHTTP-Anfrage 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 im obigen Schritt erstellte binäre HTTP-Anfrage.
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 eingegangen ist, entschlüsselt der Client sie. Die Antwort enthält den Antwortheader Content-Type im Format 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ärem HTTP wie hier gezeigt.
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();
}