API Safe Browsing Oblivious HTTP Gateway
Remarque: Cette documentation est en cours de développement. Nous prévoyons des améliorations prochainement.
L'API Safe Browsing Oblivious HTTP Gateway est une API protégeant la confidentialité basée sur le protocole RFC de l'IETF, nommée Oblivious HTTP, RFC 9458.
Présentation
L'API Safe Browsing Oblivious HTTP Gateway est un service Google qui permet aux applications clientes de vérifier les URL par rapport à des listes de ressources Web non sécurisées qui sont constamment mises à jour par Google, et qui bénéficient de protections de confidentialité supplémentaires.
Ceci est réalisé via un protocole léger appelé Oblivious HTTP, ou OHTTP en abrégé. Il s'agit d'un protocole sans état qui peut être utilisé par les clients de la navigation sécurisée pour accéder aux API Google Safe Browsing V5 afin de bénéficier de protections robustes et d'une couverture accrue sans compromettre la confidentialité des utilisateurs.
REMARQUE:Vous ne pouvez pas accéder aux API Google Safe Browsing V4 via ce service.
Protocole HTTP de la navigation sécurisée Oblivious
Protocole RFC
Oblivious HTTP est un protocole léger défini dans la RFC 9458, utilisé pour chiffrer et envoyer des messages HTTP d'un client à un serveur cible. Ce service utilise un service de relais de confiance qui limite l'utilisation par le serveur cible de métadonnées telles que l'adresse IP et les informations de connexion à des fins d'identification du client, garantissant ainsi la confidentialité et la sécurité en plus du protocole HTTP/S simple. Le protocole 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 situe entre le client et la ressource de 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, afin d'anonymiser efficacement les requêtes HTTP entrantes vers le service de passerelle. L'avantage supplémentaire 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 des clients (c'est-à-dire des hachages tronqués d'expressions d'URL) ne sont pas visibles par le relais. Consultez cet article de blog pour découvrir un exemple d'implémentation dans Chrome.
Les clients peuvent choisir n'importe quel fournisseur de relais (par exemple, Fastly) pour l'intégrer au service. Pour accéder au service, le relais doit utiliser l'authentification Oauth 2.0 avec le champ d'application d'autorisation suivant.
// 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 une 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 modifie pas la clé publique OHTTP en fonction de la clé API fournie. Les clients peuvent vérifier ce point 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, une clé API est recommandée. Cela permet aux clients d'afficher des statistiques telles que 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 savoir comment les configurer.
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 de distribution centralisée des clés afin d'extraire la clé depuis ce point de terminaison et de la distribuer ensuite à leurs applications clientes.
Conformément aux consignes de gestion des clés, les clés sont régulièrement alternées 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ée 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 diffusera la requête OHTTP qui est incluse dans le corps HTTP de la requête POST en effectuant un déchiffrement de la requête, puis chiffre la réponse OHTTP à 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 instructions du document 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 Binary HTTP, RFC 9292.
Bibliothèques clientes
Google Quiche propose des implémentations côté client pour les protocoles OHTTP et BHTTP. Il est recommandé d'utiliser ces bibliothèques aux clients. 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 de clé publique. Ensuite, initialisez la configuration de la clé OHTTP quiche comme ceci, puis initialisez le client OHTTP 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 dans un premier temps 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 chiffrera 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 inclut 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);
Après avoir déchiffré la réponse OHTTP, décodez la sortie à l'aide du 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();
}