Overview

API Navigazione sicura Oblivious HTTP Gateway

Nota: questa documentazione è attualmente in fase di sviluppo. Aspettati dei miglioramenti nel prossimo futuro.

L'API Oblivious HTTP Gateway di Navigazione sicura è un'API che garantisce la tutela della privacy e si basa sul protocollo RFC IETF denominato Oblivious HTTP, RFC 9458.

Panoramica

L'API Oblivious HTTP Gateway di Navigazione sicura è un servizio 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.

Ciò avviene mediante 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 efficaci e una maggiore copertura senza compromettere la privacy degli utenti.

NOTA: questo servizio non consente di accedere alle API V4 di Google Navigazione sicura.

Protocollo HTTP Oblivious Navigazione sicura

Protocollo RFC

Oblivious HTTP è un protocollo leggero definito nel documento RFC 9458, utilizzato per criptare e inviare i messaggi HTTP da un client a un server di destinazione. Questo utilizza un servizio di inoltro affidabile in modo da ridurre l'utilizzo da parte del server di destinazione di metadati, quali indirizzo IP e informazioni sulla connessione per l'identificazione del client, garantendo privacy e sicurezza oltre al protocollo HTTP/S normale. Il protocollo utilizza HTTP binario, definito in RFC 9292, per codificare/decodificare le richieste/risposte HTTP.

A livello generale, un inoltro si trova tra la risorsa client e quella gateway che esegue il proxy del traffico client rimuovendo tutti gli identificatori client, inclusi gli attributi sensibili alla privacy come gli indirizzi IP, anonimizzando di fatto 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 le query di Navigazione sicura dei client (ovvero hash troncati di espressioni URL) non sono visibili all'inoltro. Fai riferimento al blogpost per un esempio di implementazione in Chrome.

L'architettura complessiva del servizio.
Fig: Flusso OHTTP.

I client possono scegliere qualsiasi provider di inoltro (ad es. Rapida) per l'integrazione con il servizio. Per poter accedere al servizio, l'inoltro deve utilizzare l'autenticazione Oauth 2.0 con il seguente ambito di autorizzazione.


// OAuth Authorization scope: https://www.googleapis.com/auth/3p-relay-safe-browsing
Endpoint API
Chiave pubblica OHTTP

Questo endpoint fornirà la configurazione della chiave pubblica OHTTP, come specificato in RFC 9458, che verrà utilizzata dal client per criptare la richiesta OHTTP.


GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>

La chiave API riportata sopra non è strettamente necessaria; il server non varia la chiave pubblica OHTTP in base alla chiave API fornita. Ai client è consentito verificare questo fatto utilizzando diverse chiavi API valide per accedere a questo endpoint o non usando nessuna chiave API e verificando che la risposta contenga la stessa chiave pubblica OHTTP. Tuttavia, per semplificare il debug, è consigliabile utilizzare una chiave API, che 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 per informazioni su come configurare le chiavi API.

Come indicato nella sezione Consigli sulla privacy, al fine di raggiungere gli obiettivi di coerenza delle chiavi, consigliamo ai fornitori client di configurare un'infrastruttura di distribuzione delle chiavi centralizzata per recuperare la chiave da questo endpoint e successivamente distribuirla alle applicazioni client.

In base alle linee guida sulla 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 decrittografia.

I client dovrebbero aggiornare (recuperare e aggiornare) la chiave pubblica una volta al giorno. Se è in uso un meccanismo di distribuzione centralizzato, questo dovrebbe assicurarsi di recuperare e distribuire le chiavi una volta al giorno.

Richiesta incapsulata OHTTP

Questo endpoint gestisce la richiesta OHTTP inclusa nel corpo HTTP della richiesta POST, eseguendo la decrittografia della richiesta, e successivamente cripta la risposta OHTTP in modo che venga inoltrata a Relay nella risposta HTTP. Il client deve includere l'intestazione della richiesta Content-Type, ad esempio message/ohttp-req nella richiesta POST HTTP.


POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>

NOTA:in base alle indicazioni su 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. L'utilizzo di queste librerie è consigliato ai client. Fai riferimento allo pseudocodice di seguito 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 quiche in questo modo e inizializza il 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);

Il client utilizzerà la codifica HTTP binaria per creare una richiesta BHTTP come primo passaggio prima della crittografia.


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);

Il client cripterà successivamente 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 da Relay, il client decripta la risposta. 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(); }