La depuración de protocolos de privacidad distribuidos, como Oblivious HTTP (OHTTP), presenta desafíos inherentes debido a su arquitectura de múltiples partes, la necesidad de codificación binaria de bajo nivel y la interacción entre componentes no coludientes. Estos protocolos están diseñados para resolver el problema fundamental de la privacidad en la comunicación en línea, asegurando que ninguna entidad pueda correlacionar tanto la identidad del cliente como el contenido de su solicitud. Sin embargo, esta misma arquitectura, que distribuye la confianza y la información, introduce una complejidad significativa en el diagnóstico de fallos.
La dificultad radica en la orquestación de múltiples hops (cliente, relay, gateway, target), la gestión de claves criptográficas, y la manipulación de formatos de datos binarios como Binary HTTP (BHTTP), todo ello especificado en borradores de RFCs. La necesidad de herramientas que abstraigan esta complejidad es crítica para la adopción y el desarrollo de sistemas que implementen estos protocolos, ya que la depuración manual es propensa a errores y consume mucho tiempo. La aparición de herramientas como pvcli responde a la maduración de estos protocolos y a la necesidad de operarlos a escala de producción.
Arquitectura del Sistema
Oblivious HTTP (OHTTP) es un protocolo que garantiza la privacidad mediante la separación de la identidad del cliente y el contenido de la solicitud. Su arquitectura se basa en cuatro componentes principales: el Cliente, el Relay, el Gateway y el Target. El Cliente inicia la solicitud, el Relay reenvía la solicitud cifrada sin conocer su contenido ni el destino final, el Gateway descifra la solicitud y la envía al Target, y el Target procesa la solicitud y devuelve una respuesta que el Gateway cifra de nuevo antes de enviarla al Relay, quien finalmente la reenvía al Cliente.
La interacción comienza con el Cliente obteniendo una clave pública del Gateway. Luego, el Cliente cifra la solicitud HTTP utilizando esta clave y la envía al Relay. El Relay, actuando como un proxy de privacidad, elimina la información de origen del Cliente y reenvía la solicitud cifrada al Gateway. El Gateway descifra la solicitud, que está codificada en Binary HTTP (BHTTP), y la envía al Target. La respuesta del Target sigue el camino inverso: el Gateway la cifra, la envía al Relay, y este la reenvía al Cliente para su descifrado final. La codificación BHTTP (RFC 9292) y el cifrado OHTTP (RFC 9458) son pasos críticos que requieren una manipulación precisa de bytes. pvcli encapsula estas operaciones, automatizando la obtención de claves, el cifrado/descifrado y la codificación/decodificación BHTTP, y proporcionando visibilidad detallada de cada paso del protocolo.
Flujo de Solicitud Oblivious HTTP (OHTTP)
- 1 Cliente Obtiene clave pública del Gateway
- 2 Cliente Cifra solicitud HTTP y la envía al Relay
- 3 Relay Elimina identidad del Cliente, reenvía solicitud cifrada al Gateway
- 4 Gateway Descifra solicitud (BHTTP), la envía al Target
- 5 Target Procesa solicitud, envía respuesta al Gateway
- 6 Gateway Cifra respuesta, la envía al Relay
- 7 Relay Reenvía respuesta cifrada al Cliente
- 8 Cliente Descifra respuesta, obtiene plaintext
| Capa | Tecnología | Justificación |
|---|---|---|
| security | Oblivious HTTP (OHTTP) | Protocolo de privacidad que garantiza la separación entre la identidad del cliente y el contenido de la solicitud. |
| networking | Binary HTTP (BHTTP) | Formato de codificación binaria para solicitudes y respuestas HTTP, utilizado por OHTTP para eficiencia y compatibilidad con el cifrado. |
| compute | pvcli | Herramienta CLI de código abierto para depurar y probar protocolos de privacidad como OHTTP, automatizando la manipulación de bajo nivel. vs Scripts personalizados de curl y herramientas de criptografía, Implementaciones específicas de OHTTP en Rust/Go |
| security | DHKEM(X25519, HKDF-SHA256) | Método de encapsulación de clave (KEM) asimétrico utilizado en OHTTP para el establecimiento de claves de sesión. |
| security | AES-128-GCM | Algoritmo de cifrado simétrico con autenticación (AEAD) utilizado en OHTTP para cifrar el cuerpo de la solicitud/respuesta. |
Trade-offs
Ganancias
- ▲▲ Eficiencia en la depuración de OHTTP
- ▲ Reducción de errores humanos en la manipulación de bits
- ▲ Consistencia en las pruebas de protocolos de privacidad
Costes
pvcli -vvv --ohttp \
--first-hop https://relay-cloudflare.ohttp.info \
--proxy https://gateway.ohttp.info \
-X POST \
--header "content-type: application/json" \
--data '{"test":1}' \
https://target.ohttp.info/anythingFundamentos Teóricos
El concepto de separar la identidad del solicitante del contenido de la solicitud tiene raíces en la criptografía y los sistemas de anonimato, como los mix-nets propuestos por David Chaum en la década de 1980. Estos sistemas buscaban romper la correlación entre el origen y el destino de los mensajes mediante el reordenamiento y el cifrado en múltiples nodos. OHTTP puede verse como una evolución de estos principios, aplicando técnicas criptográficas modernas, como el cifrado homomórfico o el cifrado de clave pública con propiedades específicas, para lograr un objetivo similar en el contexto de las comunicaciones HTTP.
La dependencia de OHTTP en la no colusión entre el Relay y el Gateway es un principio fundamental en la construcción de sistemas distribuidos seguros que buscan ofrecer garantías de privacidad. Este requisito se alinea con los modelos de amenaza en los que se asume que los adversarios pueden controlar un subconjunto de nodos, pero no todos. La robustez del protocolo depende de la independencia operativa y la falta de intercambio de información fuera de banda entre estas dos partes. La estandarización a través de RFCs, como RFC 9458 para OHTTP, refleja un esfuerzo por formalizar estos principios y algoritmos en un marco interoperable y auditable, similar a cómo los protocolos de consenso distribuido como Paxos o Raft formalizan la coordinación en sistemas tolerantes a fallos.