API de Safe Browsing de HTTP Gateway
Nota: Esta documentación aún está en desarrollo. Se esperan mejoras próximamente.
La API de Oblivious HTTP Gateway para la Navegación segura es una API que preserva la privacidad basada en el protocolo IETF RFC llamado Oblivious HTTP (HTTP Oblivious) de RFC 9458.
Descripción general
La API de Oblivious HTTP Gateway de la Navegación segura es un servicio de Google que permite que las aplicaciones cliente verifiquen las URLs con las listas de Google de recursos web no seguros, las cuales se actualizan constantemente y cuentan con protecciones de privacidad adicionales.
Esto se logra a través de un protocolo ligero llamado Oblivious HTTP (Oblivious HTTP) u OHTTP para abreviar. Este es un protocolo sin estado que los clientes de Navegación segura pueden usar para acceder a las APIs de Navegación segura de Google V5 para obtener protecciones sólidas y una mayor cobertura sin comprometer la seguridad de los usuarios. la privacidad.
NOTA: No se puede acceder a las APIs de Google Safe Browsing V4 a través de este servicio.
Protocolo HTTP obvio para la Navegación segura
Protocolo RFC
HTTP obvia es un protocolo ligero definido en RFC 9458, que se usa para encriptar y enviar mensajes HTTP de un cliente a un servidor de destino. Utiliza un servicio de retransmisión confiable de una manera que mitiga el uso de metadatos del servidor de destino, como la dirección IP y la información de conexión, para la identificación del cliente, lo que proporciona privacidad y seguridad además del protocolo HTTP/S simple. El protocolo usa HTTP binario, definido en RFC 9292, para codificar y decodificar solicitudes o respuestas HTTP.
En un nivel alto, un Relay se interpone entre el cliente y el recurso de la puerta de enlace que actúa como proxy para el tráfico del cliente quitando todos los identificadores del cliente, incluidos los atributos sensibles a la privacidad, como las direcciones IP, y anonimiza de manera eficaz las solicitudes HTTP entrantes al servicio de la puerta de enlace. El beneficio adicional de OHTTP es que todas las solicitudes están encriptadas de extremo a extremo, lo que significa que las solicitudes Relay no puede ver las consultas de Navegación segura (es decir, hashes truncados de expresiones de URL). Consulta la blogpost para ver un ejemplo de implementación en Chrome.
Los clientes pueden elegir cualquier proveedor de Relay (p. ej., Fastly) para integrar el servicio. Para acceder al servicio, el Relay debe usar la autenticación Oauth 2.0 con el siguiente permiso de autorización.
// OAuth Authorization scope:
https://www.googleapis.com/auth/3p-relay-safe-browsing
Extremos de la API
Clave pública de OHTTP
Este extremo proporcionará la configuración de la clave pública de OHTTP como se especifica en RFC 9458, que el cliente usará para encriptar la solicitud de OHTTP.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
La clave de API anterior no es estrictamente necesaria. El servidor no modifica la clave pública de OHTTP en función de la clave de API proporcionada. Los clientes pueden comprobar esto usando diferentes claves de API válidas para acceder a este extremo o sin usar claves de API por completo, y verificando que la respuesta efectivamente contenga la misma clave pública de OHTTP. Sin embargo, para facilitar la depuración, se recomienda usar una clave de API. Esto permite a los clientes ver estadísticas, como la cantidad de solicitudes en la consola de Google Cloud. Si el cliente desea proporcionar una clave de API, consulta esta documentación sobre cómo configurarlas.
Como se indica en la sección de recomendaciones de privacidad, para cumplir con los objetivos de coherencia de claves, se recomienda a los proveedores de clientes que configuren una infraestructura de distribución de claves centralizada para recuperar la clave de este extremo y, luego, distribuirla a sus aplicaciones cliente.
Según la guía de administración de claves, las claves se rotan con regularidad en el servidor. Los clientes deben actualizar la clave, es decir, recuperar y actualizar la copia local de la clave de vez en cuando para evitar errores de desencriptación.
Los clientes deben actualizar (recuperar y actualizar) la clave pública una vez al día. Si se utiliza un mecanismo de distribución centralizada, este mecanismo debe asegurarse de recuperar y distribuir las claves una vez al día.
Solicitud encapsulada de OHTTP
Este extremo entregará la solicitud OHTTP que se incluye en el cuerpo HTTP de la solicitud POST mediante la desencriptación de la solicitud y, luego, encriptará la respuesta OHTTP para que se reenvíe a Relay en la respuesta HTTP. El cliente debe incluir el encabezado de la solicitud Content-Type como message/ohttp-req en la solicitud HTTP POST.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
NOTA: Según la guía sobre RFC, codifica la solicitud interna (consulta la documentación de V5 sobre cómo crear una solicitud de Navegación segura) con el protocolo HTTP binario, RFC 9292.
Bibliotecas cliente
Google Quiche tiene implementaciones del lado del cliente para los protocolos OHTTP y BHTTP. Se recomienda que los clientes usen estas bibliotecas. Consulta el siguiente seudocódigo sobre cómo crear solicitudes OHTTP para acceder a la API.
Ejemplo de implementación del lado del cliente
Los clientes recuperan la clave pública HTTP Oblivious desde el extremo de clave pública. Luego, inicializa la configuración de la clave de OHTTP de quiche de esta manera y, luego, inicializa el cliente de OHTTP de 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);
El cliente usará la codificación HTTP binaria para crear una solicitud BHTTP como primer paso antes de la encriptación.
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);
El Cliente encriptará luego la solicitud HTTP Binaria creada en el paso anterior.
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 vez que se reciba la respuesta de Relay, el cliente la desencriptará. La respuesta incluirá el encabezado de respuesta Content-Type como ohttp-res.
auto ctx = std::move(ohttp_request).ReleaseContext();
auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);
Después de desencriptar la respuesta de OHTTP correctamente, decodifica el resultado con HTTP binario de esta manera.
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();
}