Interfejs API bramy HTTP Oblivious HTTP Safe Browsing
Uwaga: ta dokumentacja jest nadal w fazie rozwoju. W najbliższej przyszłości spodziewaj się ulepszeń.
Safe Browsing Oblivious HTTP Gateway API to chroniący prywatność interfejs API oparty na protokole RFC IETF o nazwie Oblivious HTTP, RFC 9458.
Omówienie
Interfejs Safe Browsing Oblivious HTTP Gateway API to usługa Google, która umożliwia aplikacjom klienckim sprawdzanie adresów URL pod kątem nieustannie aktualizowanych list niebezpiecznych zasobów internetowych, które zapewniają dodatkową ochronę prywatności.
Jest to możliwe za pomocą lekkiego protokołu o nazwie Oblivious HTTP (W skrócie OHTTP). Jest to bezstanowy protokół, którego mogą używać klienci Bezpiecznego przeglądania do uzyskiwania dostępu do interfejsów API Bezpiecznego przeglądania Google (wersja 5). Pozwala to uzyskać niezawodną ochronę i zwiększony zasięg bez naruszania praw użytkowników prywatności.
UWAGA: za pomocą tej usługi nie można uzyskać dostępu do interfejsów API Bezpiecznego przeglądania Google w wersji 4.
Bezpieczny protokół HTTP Bezpiecznego przeglądania
Protokół RFC
Oblivious HTTP to prosty protokół zdefiniowany w RFC 9458, który służy do szyfrowania i wysyłania wiadomości HTTP z klienta na serwer docelowy. Korzysta to z zaufanej usługi przekaźnika w sposób, który ogranicza wykorzystywanie metadanych, takich jak adres IP i informacje o połączeniu przez serwer docelowy, do identyfikacji klienta, a ponadto zwykły protokół HTTP/S zapewnia prywatność i bezpieczeństwo. Do kodowania/dekodowania żądań/odpowiedzi HTTP protokół używa Binary HTTP, zdefiniowanego w RFC 9292.
Ogólnie rzecz biorąc, usługa Relay znajduje się między zasobem klienta i bramy, która pośredniczy w ruchu klientów, usuwając wszystkie identyfikatory klientów, w tym atrybuty poufne dotyczące prywatności, takie jak adresy IP. Skutecznie anonimizuje przychodzące żądania HTTP do usługi bramy. Dodatkową zaletą protokołu OHTTP jest to, że wszystkie żądania są w pełni szyfrowane, co oznacza, że Zapytania dotyczące Bezpiecznego przeglądania (tj. obcięte hasze wyrażeń adresów URL) nie są widoczne dla usługi Relay. Przykład implementacji w Chrome znajdziesz w blogpost.
Klienty mogą wybrać dowolnego dostawcę usługi przekaźnika (np. Fastly) do integracji z usługą. Aby uzyskać dostęp do usługi, Relay musi używać uwierzytelniania Oauth 2.0 z poniższym zakresem autoryzacji.
// OAuth Authorization scope:
https://www.googleapis.com/auth/3p-relay-safe-browsing
Punkty końcowe interfejsu API
Klucz publiczny OHTTP
Ten punkt końcowy będzie zawierał konfigurację klucza publicznego OHTTP zgodnie z opisem w RFC 9458, która będzie używana przez klienta do szyfrowania żądania OHTTP.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
Powyższy klucz interfejsu API nie jest absolutnie niezbędny. serwer nie różni się kluczem publicznym OHTTP na podstawie podanego klucza interfejsu API. Klienty mogą sondować ten fakt, korzystając z różnych prawidłowych kluczy interfejsu API w celu uzyskania dostępu do tego punktu końcowego lub nie używając w ogóle żadnych kluczy interfejsu API oraz sprawdzając, czy odpowiedź rzeczywiście zawiera ten sam klucz publiczny OHTTP. Aby jednak ułatwić debugowanie, zalecany jest klucz interfejsu API. umożliwia to klientom wyświetlanie statystyk, takich jak liczba żądań w konsoli Google Cloud. Jeśli klient zamierza dostarczyć klucz interfejsu API, zapoznaj się z tą dokumentacją dotyczącą konfigurowania kluczy interfejsu API.
Jak opisano w sekcji Zalecenia dotyczące prywatności, w celu osiągnięcia kluczowych celów spójności zalecamy dostawcom klientów skonfigurowanie infrastruktury scentralizowanej dystrybucji kluczy w celu pobierania klucza z tego punktu końcowego, a następnie rozpowszechniania go w aplikacjach klienckich.
Zgodnie ze wskazówkami dotyczącymi zarządzania kluczami klucze są regularnie poddawane rotacji na serwerze. Klienty powinny co jakiś czas odświeżać klucz, czyli pobierać i aktualizować lokalną kopię klucza, aby uniknąć błędów podczas odszyfrowywania.
Klienty powinny odświeżać (pobierać i aktualizować) klucz publiczny raz dziennie. Jeśli używany jest scentralizowany mechanizm dystrybucji, powinien on pobierać i rozpowszechniać klucze raz dziennie.
Żądanie zakodowane przez OHTTP
Ten punkt końcowy będzie obsługiwać żądanie OHTTP uwzględnione w treści żądania HTTP przez odszyfrowywanie żądania, a następnie zaszyfrować odpowiedź OHTTP, która zostanie przekazana z powrotem do usługi Relay w odpowiedzi HTTP. Klient musi uwzględnić nagłówek żądania Content-Type w postaci message/ohttp-req w żądaniu HTTP POST.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
UWAGA: zgodnie ze wskazówkami w dokumencie RFC zakoduj żądanie wewnętrzne (przeczytaj dokumentację V5, jak utworzyć żądanie Bezpiecznego przeglądania), używając protokołu Binary HTTP RFC 9292.
Biblioteki klienta
Google Quiche zawiera implementacje po stronie klienta zarówno dla protokołów OHTTP, jak i BHTTP. Klientom zalecamy korzystanie z tych bibliotek. Aby uzyskać dostęp do interfejsu API, zapoznaj się z poniższym pseudokodem, aby dowiedzieć się, jak tworzyć żądania OHTTP.
Przykładowa implementacja po stronie klienta
Klienty pobierają klucz publiczny HTTP Oblivious z punktu końcowego klucza publicznego. Następnie zainicjuj w ten sposób konfigurację klucza OHTTP do picia i zainicjuj klienta OHTTP do quizu.
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);
W pierwszym kroku przed zaszyfrowaniem klient użyje kodowania binarnego HTTP do utworzenia żądania BHTTP.
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);
Klient zaszyfruje następnie żądanie Binary HTTP utworzone w powyższym kroku.
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();
Po otrzymaniu odpowiedzi z usługi Relay klient ją odszyfruje. Odpowiedź będzie zawierać nagłówek odpowiedzi Content-Type w postaci ohttp-res.
auto ctx = std::move(ohttp_request).ReleaseContext();
auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);
Po odszyfrowaniu odpowiedzi OHTTP zdekoduj dane wyjściowe za pomocą protokołu Binary HTTP w podobny sposób.
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();
}