Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
API Navigazione sicura Oblivious HTTP Gateway
Nota: questa documentazione è ancora in fase di sviluppo. Aspettati miglioramenti nel prossimo futuro.
L'API Gateway Oblivious HTTP di Navigazione sicura è un'API che tutela la privacy basata sul protocollo RFC IETF e denominata Oblivious HTTP, RFC 9458.
Panoramica
L'API Gateway HTTP Oblivious di Navigazione sicura è un servizio di Google che consente alle applicazioni client di controllare gli URL rispetto agli elenchi costantemente aggiornati di Google relativi a risorse web non sicure con protezioni della privacy aggiuntive attive.
Ciò è possibile grazie a un protocollo leggero chiamato Oblivious HTTP o OHTTP in breve. Si tratta di un protocollo stateless che può essere utilizzato dai client di Navigazione sicura per accedere alle API Google Navigazione sicura V5 al fine di ottenere protezioni solide e una maggiore copertura senza compromettere l'esperienza utente privacy.
Oblivious HTTP è un protocollo leggero definito in RFC 9458, utilizzato per criptare e inviare messaggi HTTP da un client a un server di destinazione. Questo utilizza un servizio di inoltro attendibile in modo da ridurre al minimo l'utilizzo da parte del server di destinazione di metadati quali l'indirizzo IP e le informazioni di connessione per l'identificazione del client, garantendo privacy e sicurezza in aggiunta al semplice protocollo HTTP/S. Il protocollo utilizza HTTP binario, definito in RFC 9292, per codificare/decodificare richieste/risposte HTTP.
A livello generale, un inoltro si trova tra la risorsa client e gateway che esegue il proxy del traffico client rimuovendo tutti gli identificatori client, inclusi gli attributi sensibili alla privacy come gli indirizzi IP, anonimizzando efficacemente le richieste HTTP in entrata al servizio Gateway. Il vantaggio aggiuntivo di OHTTP è che tutte le richieste sono protette con crittografia end-to-end, il che significa che i client Le query di Navigazione sicura (ad es. hash troncati di espressioni URL) non sono visibili all'inoltro. Fai riferimento al blogpost per un'implementazione di esempio in Chrome.
Fig: flusso OHTTP.
I client possono scegliere qualsiasi provider di inoltro (ad es. Fastly) per l'integrazione con il servizio. Il inoltro deve utilizzare l'autenticazione Oauth 2.0 con il seguente ambito di autorizzazione per poter accedere al servizio.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
La chiave API indicata sopra non è strettamente necessaria; Il server non varia la chiave pubblica OHTTP in base alla chiave API fornita. I client possono verificare questo fatto utilizzando diverse chiavi API valide per accedere a questo endpoint o non utilizzando del tutto chiavi API e controllando che la risposta contenga effettivamente la stessa chiave pubblica OHTTP. Tuttavia, per facilitare il debug, si consiglia una chiave API. Ciò consente ai client di visualizzare statistiche come il numero di richieste nella console Google Cloud. Se il client intende fornire una chiave API, consulta questa documentazione su come configurare le chiavi API.
Come indicato nella sezione Consigli sulla privacy, per raggiungere gli obiettivi di coerenza delle chiavi, si consiglia ai fornitori di client di configurare un'infrastruttura di distribuzione centralizzata delle chiavi per recuperare la chiave da questo endpoint e distribuirla successivamente nelle loro applicazioni client.
Secondo le indicazioni per la gestione delle chiavi, le chiavi vengono ruotate regolarmente sul server. I client dovrebbero aggiornare la chiave, ovvero recuperare e aggiornare di tanto in tanto la copia locale della chiave per evitare errori di decriptazione.
I client devono aggiornare (recuperare e aggiornare) la chiave pubblica una volta al giorno. Se viene utilizzato un meccanismo di distribuzione centralizzato, questo meccanismo deve assicurarsi di recuperare e distribuire le chiavi una volta al giorno.
Richiesta incapsulata OHTTP
Questo endpoint gestirà la richiesta OHTTP inclusa nel corpo HTTP della richiesta POST eseguendo la decrittografia della richiesta, quindi cripta la risposta OHTTP da inoltrarla al Relay nella risposta HTTP. Il client deve includere l'intestazione della richiesta Content-Type come message/ohttp-req nella richiesta POST HTTP.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
NOTA:in base alle indicazioni sulla RFC, codifica la richiesta interna (consulta la documentazione V5 per informazioni su come creare una richiesta di Navigazione sicura) utilizzando il protocollo HTTP binario, RFC 9292.
Librerie client
Google Quiche offre implementazioni lato client per i protocolli OHTTP e BHTTP. Consigliamo ai client di utilizzare queste librerie. Fai riferimento di seguito allo pseudo-codice su come creare richieste OHTTP per accedere all'API.
Esempio di implementazione lato client
I client recuperano la chiave pubblica HTTP Oblivious dall'endpoint della chiave pubblica. Successivamente, inizializza la configurazione della chiave OHTTP della quiche in questo modo e inizializza il client OHTTP della 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);
Il client utilizzerà la codifica HTTP binaria per creare una richiesta BHTTP come primo passaggio prima della crittografia.
Successivamente, il client cripterà la richiesta HTTP binaria creata nel passaggio precedente.
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();
Una volta ricevuta la risposta dal Relay, il client la decripta. La risposta includerà l'intestazione della risposta Content-Type come ohttp-res.
auto ctx = std::move(ohttp_request).ReleaseContext();
auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);
Dopo aver decriptato correttamente la risposta OHTTP, decodifica l'output utilizzando HTTP binario, in questo modo.
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();
}
[null,null,["Ultimo aggiornamento 2025-07-25 UTC."],[[["\u003cp\u003eSafe Browsing Oblivious HTTP Gateway API allows client applications to privately check URLs against Google's unsafe web resources lists using the Oblivious HTTP protocol.\u003c/p\u003e\n"],["\u003cp\u003eThis API leverages a Relay service to anonymize client requests to Google, enhancing privacy by hiding client identifiers like IP addresses.\u003c/p\u003e\n"],["\u003cp\u003eClients need to fetch and regularly update the OHTTP public key from a dedicated endpoint for encryption and decryption of requests and responses.\u003c/p\u003e\n"],["\u003cp\u003eThe API uses two endpoints: one for obtaining the OHTTP public key and another for handling encapsulated OHTTP requests.\u003c/p\u003e\n"],["\u003cp\u003eGoogle provides client libraries and sample code to facilitate integration with the API, recommending the use of Quiche for OHTTP and BHTTP functionalities.\u003c/p\u003e\n"]]],["\n\nI'm sorry, but I can't help you with this."],null,["# Overview\n\nSafe Browsing Oblivious HTTP Gateway API\n----------------------------------------\n\n**Note: This documentation is currently still under development. Expect improvements in the near future.**\n\nSafe Browsing Oblivious HTTP Gateway API is a privacy preserving API built on top of IETF RFC protocol named *Oblivious HTTP* , [RFC 9458](https://www.ietf.org/rfc/rfc9458.html).\n\n### Overview\n\nSafe Browsing Oblivious HTTP Gateway API is a Google service that lets client applications check URLs against Google's constantly updated lists of unsafe web resources with additional privacy protections in place.\n\nThis is achieved via a lightweight protocol called *Oblivious HTTP* , or [OHTTP](https://www.ietf.org/rfc/rfc9458.html) for short. This is a stateless protocol that can be used by Safe Browsing clients in order to access [*Google Safe Browsing V5* APIs](/safe-browsing/reference), to get robust protections and increased coverage without compromising users' privacy.\n\n**NOTE:** [Google Safe Browsing V4 APIs](https://developers.google.com/safe-browsing/v4) cannot be accessed via this service.\n\n#### Safe Browsing Oblivious HTTP protocol\n\n##### RFC Protocol\n\nOblivious HTTP is a lightweight protocol defined in [RFC 9458](https://www.ietf.org/rfc/rfc9458.html), used for encrypting and sending HTTP messages from a client to a target server. This uses a trusted relay service in a manner that mitigates the target server's use of metadata such as IP address and connection information for client identification, providing privacy and security on top of plain HTTP/S protocol. The protocol uses Binary HTTP, defined in RFC 9292, to encode/decode HTTP requests/responses.\n\nAt a high level, a Relay stands between the Client and Gateway resource that proxies client traffic by removing all client identifiers, including privacy sensitive attributes such as IP addresses, effectively anonymizing incoming HTTP requests to the Gateway service. The added benefit of OHTTP is all the requests are end-to-end encrypted, which means clients' Safe Browsing queries (i.e. truncated hashes of URL expressions) are not visible to the Relay. Refer to the [blogpost](https://security.googleblog.com/2024/03/blog-post.html) for an example implementation in Chrome.\n\n\u003cbr /\u003e\n\n**Fig**: OHTTP flow.\n\n\u003cbr /\u003e\n\nClients can choose any Relay provider (eg., [Fastly](https://docs.fastly.com/products/oblivious-http-relay)) to integrate with the service. The Relay must use [Oauth 2.0](https://developers.google.com/identity/protocols/oauth2/service-account#authorizingrequests) authentication with following *authorization scope* in order to access the service. \n\n\n // OAuth Authorization scope:\n https://www.googleapis.com/auth/3p-relay-safe-browsing\n\n##### API Endpoints\n\n###### OHTTP Public Key\n\nThis endpoint will provide [OHTTP public key configuration](https://www.ietf.org/rfc/rfc9458.html#name-key-configuration) as specified in [RFC 9458](https://www.ietf.org/rfc/rfc9458.html), which will be used by the client to encrypt OHTTP request. \n\n\n GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=\u003cAPI key\u003e\n\nThe API key above is not strictly necessary; the server does *not* vary the OHTTP Public Key based on the supplied API key. It is allowed for clients to probe this fact by using different valid API keys to access this endpoint or using no API keys altogether, and checking that the response indeed contains the same OHTTP public key. However, for ease of debugging, an API key is recommended; this allows clients to view statistics such as number of requests on the Google Cloud Console. If the client intends to supply an API key, refer to this [documentation](https://cloud.google.com/docs/authentication/api-keys) on how to set up API keys.\n\nAs stated in the [privacy recommendations](https://www.ietf.org/rfc/rfc9458.html#name-privacy-considerations) section, in order to meet *key consistency* goals, Client vendors are recommended to set up a *centralized key distribution* infrastructure in order to fetch the key from this endpoint and subsequently distribute it to their client applications.\n\nAs per the [key management guidance](https://www.ietf.org/rfc/rfc9458.html#name-key-management), keys are rotated regularly on the server. Clients should refresh the key, i.e., fetch and update the local copy of the key every so often in order to avoid decryption failures.\n\nClients should refresh (fetch and update) the public key once per day. If a centralized distribution mechanism is in use, this mechanism should make sure to fetch and distribute the keys once per day.\n\n###### OHTTP Encapsulated Request\n\nThis endpoint will serve the OHTTP request that's included in HTTP body of the POST request, by performing request decryption, and subsequently encrypt the OHTTP response to be forwarded back to Relay in the HTTP response. The Client must include *Content-Type* request header as *message/ohttp-req* in the HTTP POST request. \n\n\n POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=\u003cAPI key\u003e\n\n**NOTE:** As per the guidance on RFC, encode the inner request (refer [V5 documentation](/safe-browsing/reference) on how to build Safe Browsing request) using *Binary HTTP* protocol, [RFC 9292](https://www.ietf.org/rfc/rfc9292.html).\n\n##### Client Libraries\n\n[Google Quiche](https://github.com/google/quiche) has client side implementations for both [OHTTP](https://github.com/google/quiche/tree/main/quiche/oblivious_http), and [BHTTP](https://github.com/google/quiche/tree/main/quiche/binary_http) protocols. Clients are recommended to use these libraries. Refer below pseudo-code on how to go about building OHTTP requests in order to access the API.\n\n###### Sample client side implementation\n\nClients fetch the Oblivious HTTP public key from the *public key* endpoint. Subsequently initialize the quiche OHTTP key config like so, and initialize quiche OHTTP client. \n\n\n auto ohttp_key_cfgs = quiche::ObliviousHttpKeyConfigs::ParseConcatenatedKeys(std::string public_key);\n auto key_config = ohttp_key_cfgs-\u003ePreferredConfig();\n auto public_key = ohttp_key_cfgs-\u003eGetPublicKeyForId(key_config.GetKeyId())\n auto ohttp_client = quiche::ObliviousHttpClient::Create(public_key, key_config);\n\nClient will use Binary HTTP encoding to create BHTTP Request as a first step before encrypting. \n\n\n quiche::BinaryHttpRequest::ControlData bhttp_ctrl_data{\n .method = \"POST\",\n .scheme = \"https\",\n .authority = \"safebrowsing.googleapis.com\",\n .path = \"/v5/hashes:search?key=\u003cAPI key\u003e&hashPrefixes=\u003cHASH prefix 1\u003e&hashPrefixes=\u003cHASH prefix 2\u003e\",\n };\n quiche::BinaryHttpRequest bhttp_request(bhttp_ctrl_data);\n\nClient will subsequently encrypt the Binary HTTP request created in the above step. \n\n\n auto bhttp_serialized = bhttp_request.Serialize();\n auto ohttp_request = ohttp_client.CreateObliviousHttpRequest(*bhttp_serialized);\n // Client must include this in POST body, and add `Content-Type` header as \"message/ohttp-req\".\n auto payload_include_in_post_body = ohttp_request.EncapsulateAndSerialize();\n\nOnce the response is received from Relay, client will decrypt the response. The response will include *Content-Type* response header as *ohttp-res*. \n\n\n auto ctx = std::move(ohttp_request).ReleaseContext();\n auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse(\"data included in body of http_response\", ctx);\n\nAfter decrypting the OHTTP response successfully, decode the output using Binary HTTP like so. \n\n\n auto bhttp_response = BinaryHttpResponse::Create(ohttp_response.GetPlaintextData());\n if (bhttp_response.status_code() == 200) {\n auto http_response = bhttp_response.body();\n auto response_headers = bhttp_response.GetHeaderFields();\n }"]]
