API Safe Browsing Oblivious HTTP Gateway
Remarque: Cette documentation est en cours de développement. Nous prévoyons des améliorations dans un avenir proche.
L'API Safe Browsing HTTP Gateway est une API de protection de la confidentialité basée sur le protocole RFC de l'IETF, nommée Oblivious HTTP et RFC 9458.
Présentation
L'API Safe Browsing HTTP Gateway est un service Google qui permet aux applications clientes de comparer les URL à des listes de ressources Web non sécurisées qui sont constamment mises à jour par Google, tout en mettant en place des protections de la confidentialité supplémentaires.
Pour ce faire, utilisez un protocole léger appelé Oblivious HTTP (ou OHTTP en abrégé). Il s'agit d'un protocole sans état qui permet aux clients de navigation sécurisée d'accéder aux API Google Safe Browsing V5 afin de bénéficier de protections solides et d'une couverture accrue sans compromettre les utilisateurs confidentialité.
REMARQUE:Vous ne pouvez pas accéder aux API Google Safe Browsing V4 via ce service.
Protocole HTTP non sécurisé de la navigation sécurisée
Protocole RFC
Oblivious HTTP est un protocole léger défini dans le document RFC 9458. Il permet de chiffrer et d'envoyer des messages HTTP d'un client à un serveur cible. Il utilise un service de relais de confiance de manière à limiter l'utilisation par le serveur cible de métadonnées telles que l'adresse IP et les informations de connexion pour l'identification du client, ce qui assure la confidentialité et la sécurité par rapport au protocole HTTP/S standard. Il utilise le protocole HTTP binaire, défini dans le document RFC 9292, pour encoder/décoder les requêtes/réponses HTTP.
De manière générale, un relais se trouve entre les ressources "Client" et "Passerelle" qui sert de proxy pour le trafic client en supprimant tous les identifiants client, y compris les attributs sensibles à la confidentialité tels que les adresses IP. Les requêtes HTTP entrantes sont ainsi anonymisées auprès du service de passerelle. L'avantage d'OHTTP est que toutes les requêtes sont chiffrées de bout en bout, ce qui signifie que Les requêtes de navigation sécurisée (hachages tronqués d'expressions d'URL) ne sont pas visibles par Relay. Consultez blogpost pour découvrir un exemple d'implémentation dans Chrome.
Les clients peuvent choisir n'importe quel fournisseur Relay (par exemple, Fastly) pour intégrer le service. Relay doit utiliser l'authentification Oauth 2.0 avec le champ d'application d'autorisation suivant pour pouvoir accéder au service.
// OAuth Authorization scope:
https://www.googleapis.com/auth/3p-relay-safe-browsing
Points de terminaison de l'API
Clé publique OHTTP
Ce point de terminaison fournira la configuration de clé publique OHTTP comme spécifié dans le document RFC 9458, qui permettra au client de chiffrer la requête OHTTP.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
La clé API ci-dessus n'est pas strictement nécessaire. le serveur ne fait pas varier la clé publique OHTTP en fonction de la clé API fournie. Les clients peuvent vérifier ce fait en utilisant différentes clés API valides pour accéder à ce point de terminaison ou en n'utilisant aucune clé API, et en vérifiant que la réponse contient bien la même clé publique OHTTP. Toutefois, pour faciliter le débogage, nous vous recommandons d'utiliser une clé API. Les clients peuvent ainsi consulter des statistiques comme le nombre de requêtes dans la console Google Cloud. Si le client a l'intention de fournir une clé API, consultez cette documentation pour découvrir comment configurer des clés API.
Comme indiqué dans la section Recommandations en matière de confidentialité, afin d'atteindre les objectifs de cohérence des clés, nous recommandons aux fournisseurs clients de configurer une infrastructure centralisée de distribution des clés. Cela leur permettra d'extraire la clé de ce point de terminaison et de la distribuer ensuite à leurs applications clientes.
Conformément aux conseils concernant la gestion des clés, les clés sont alternées régulièrement sur le serveur. Les clients doivent actualiser la clé, c'est-à-dire récupérer et mettre à jour la copie locale de la clé de temps en temps afin d'éviter les échecs de déchiffrement.
Les clients doivent actualiser (extraire et mettre à jour) la clé publique une fois par jour. Si un mécanisme de distribution centralisé est utilisé, ce mécanisme doit veiller à récupérer et à distribuer les clés une fois par jour.
Requête encapsulée OHTTP
Ce point de terminaison diffuse la requête OHTTP incluse dans le corps HTTP de la requête POST en effectuant le déchiffrement de la requête, puis il chiffre la réponse OHTTP pour la renvoyer à Relay dans la réponse HTTP. Le client doit inclure l'en-tête de requête Content-Type sous la forme message/ohttp-req dans la requête HTTP POST.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
REMARQUE:Conformément aux consignes RFC, encodez la requête interne (consultez la documentation V5 pour savoir comment créer une requête de navigation sécurisée) à l'aide du protocole HTTP binaire, RFC 9292.
Bibliothèques clientes
Google Quiche dispose d'implémentations côté client pour les protocoles OHTTP et BHTTP. Nous recommandons aux clients d'utiliser ces bibliothèques. Reportez-vous au pseudo-code ci-dessous pour découvrir comment créer des requêtes OHTTP afin d'accéder à l'API.
Exemple d'implémentation côté client
Les clients récupèrent la clé publique HTTP Oblivious à partir du point de terminaison public key (clé publique). Ensuite, initialisez la configuration de la clé OHTTP de la quiche de la même manière, puis initialisez le client OHTTP du 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);
Le client utilisera l'encodage HTTP binaire pour créer une requête BHTTP comme première étape avant le chiffrement.
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);
Le client chiffre ensuite la requête HTTP binaire créée à l'étape ci-dessus.
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();
Une fois la réponse reçue de Relay, le client la déchiffre. La réponse inclura l'en-tête de réponse Content-Type sous la forme ohttp-res.
auto ctx = std::move(ohttp_request).ReleaseContext();
auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);
Une fois la réponse OHTTP déchiffrée, vous devez décoder la sortie à l'aide du protocole HTTP binaire comme ceci.
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();
}