Resumen

  • RFC 9458 divide el conocimiento de una petición: el relé conoce el origen de red y no el texto claro; la puerta de enlace conoce el texto claro y no el origen del cliente. La norma exige que ambos papeles no pertenezcan a la misma entidad para cumplir su objetivo de privacidad.
  • El reparto se rompe si la aplicación introduce una identidad alternativa o si la operación vuelve a ensamblar los datos: cookies, credenciales, configuraciones únicas, contextos HPKE reutilizados, trazas comunes, poco volumen y coincidencias de tiempo o tamaño son vías de correlación.
  • Christopher A. Wood, coautor de la RFC con Martin Thomson, ayudó a convertir esa separación en una propiedad técnica examinable. La prueba decisiva de una implantación no es que cifre, sino que conserve operadores independientes, claves efímeras, reintentos seguros y un conjunto de anonimato suficiente.

Análisis: dos registros que nunca deberían convertirse en uno

Un registro del relé podría decir: a las 10:02 llegó un objeto cifrado desde cierta dirección. Otro registro, en la puerta de enlace, podría decir: a las 10:02 llegó una consulta sobre un asunto sensible. Separados, ninguno cuenta la historia completa. Unidos, la privacidad desaparece sin necesidad de romper el cifrado.

Esa posibilidad explica el diseño de Oblivious HTTP. El cliente codifica una petición HTTP binaria, crea una envoltura HPKE con la configuración pública de una puerta de enlace y la envía por HTTPS a un relé. El relé recibe la conexión del cliente y sabe a qué puerta reenviar, pero no posee la clave para leer el contenido. Abre una segunda conexión HTTPS hacia la puerta de enlace. Allí se descapsula la petición, se consulta el recurso de destino y la respuesta se protege para volver por el mismo relé.

El relé conserva la procedencia de red y pierde el contenido. La puerta conserva el contenido y pierde la procedencia. RFC 9458 afirma que ambos no pueden ser la misma entidad si se pretende alcanzar los fines de privacidad del protocolo.

La frase no se cumple por dibujar dos rectángulos. Si una sola cuenta privilegiada administra los dos servicios, si sus registros llegan al mismo lago de datos o si una política de incidentes permite exportarlos sin límite, la organización puede rehacer la asociación que el trayecto evitó. La exigencia explícita es la no coincidencia de entidad; considerar también la separación jurídica, administrativa y de datos es una inferencia operativa. Es una inferencia necesaria para saber si la arquitectura existe fuera del diagrama.

Una biografía técnica sin atribución excesiva

La RFC se publicó en enero de 2024 como norma de la vía Standards Track y está firmada por Martin Thomson y Christopher A. Wood. La ficha del IETF conservada el 1 de septiembre de 2026 describe a Wood como ingeniero de Apple dedicado a ingeniería criptográfica y enumera 24 RFC vinculadas a su identidad pública. Es una fotografía temporal, no una licencia para atribuirle todos los antecedentes de OHTTP ni las decisiones de cada operador.

Wood comparte además con Jonathan Hoyland un análisis formal publicado por Cloudflare en 2022. El modelo usa Tamarin para representar mensajes, claves, sesiones TLS y compromisos. El adversario puede observar la red y comprometer adaptativamente al relé o a la puerta, pero el modelo presupone que ambos no colaboran y prohíbe trasladar identificadores del cliente a la puerta.

Entre las propiedades comprobadas aparecen secreto, consistencia, enlace entre petición y respuesta y uso de nonces. La conclusión sobre desvinculación tiene un alcance concreto: bajo esas reglas, conocer a la vez la consulta y la conexión cifrada que recibió el relé requiere comprometer los dos papeles. Los autores advierten que eso no prueba indistinguibilidad en general. Un patrón estadístico puede delatar lo que el álgebra mantiene secreto.

La prudencia forma parte de la aportación. El modelo permite revisar afirmaciones mucho más precisas que «privacidad mejorada», pero no observa si una empresa comparte personal, telemetría, contratos o retención. Una prueba formal es evidencia sobre el mecanismo modelado. La explotación necesita otra prueba sobre las condiciones que rodean al mecanismo.

La puerta de enlace también es un punto de confianza

El cliente no establece mediante OHTTP una autenticación directa con el recurso de destino. La protección del mensaje termina en la puerta de enlace. Esta puede escoger la respuesta que devuelve y es quien se comunica con el destino. Por eso el cliente debe autorizar una puerta para un destino concreto y autenticar la configuración de clave que utiliza.

Este matiz impide vender OHTTP como un túnel transparente de extremo a extremo. Una regla como el anclaje de certificado del destino no atraviesa automáticamente una terminación intermediada. El equipo de aplicación tiene que documentar qué objetivos puede alcanzar la puerta, cómo se entrega su configuración a los clientes, quién la firma y qué ocurre si alguien intenta sustituirla.

También tiene que evitar que la propia configuración funcione como matrícula. Una clave o combinación de parámetros asignada a un solo dispositivo divide el conjunto de anonimato hasta dejarlo en una persona. Rotar claves sin solapamiento suficiente puede crear cohortes temporales diminutas. El control no consiste solo en comprobar la firma: debe medir cuántos clientes comparten cada configuración activa.

En el otro extremo, el destino debe aceptar únicamente puertas autorizadas y proteger con HTTPS una conexión de origen separado. Estas restricciones reducen desvíos, pero no convierten a la puerta en el destino que el cliente cree autenticar. La distinción debe permanecer visible en la interfaz y en el análisis de amenazas.

Cuando el contenido pronuncia el nombre

Una petición cifrada puede transportar una cookie de cuenta. Puede incluir un encabezado de autorización, un identificador de instalación, un idioma poco frecuente o un token de diagnóstico repetido. La puerta de enlace no necesita ver la dirección IP si ese contenido ya identifica al usuario.

RFC 9458 limita el valor de la desvinculación de transporte a aplicaciones que no mantienen estado correlacionable dentro de la petición. Esa condición no se verifica leyendo la documentación del producto. Hay que inspeccionar el mensaje binario justo antes de encapsularlo y repetir la inspección después de cada cambio de biblioteca.

Los caminos de error importan tanto como el normal. Un SDK puede retirar cookies en el primer envío y añadir un identificador estable al reintentar. Un servicio puede devolver un código único que el cliente reenvía. Un sistema antifraude puede insertar una puntuación tan singular que se convierte en seudónimo. La minimización tiene que cubrir encabezados, cuerpo, parámetros, tamaños y valores derivados.

El relé tampoco debe añadir Via o Forwarded con información de origen. Un solo encabezado puede deshacer todo el reparto de conocimiento. La revisión más útil coloca una sonda antes de HPKE y otra después de la puerta de enlace, y compara no solo igualdad funcional, sino capacidad de identificación.

Un contexto nuevo no arregla una acción duplicada

HPKE, estandarizado en RFC 9180, combina encapsulación de clave, derivación y cifrado autenticado para establecer el contexto de cada intercambio. OHTTP exige crear uno nuevo por petición. Reutilizarlo facilita la correlación y puede abrir fallos de confidencialidad frente al relé.

Pero la frescura criptográfica no resuelve por sí sola el significado de repetir una operación. Si el cliente no recibe respuesta, la puerta quizá haya procesado la solicitud. Volver a enviarla con un contexto nuevo evita reutilizar claves, pero todavía puede ejecutar dos veces un cambio de estado. La aplicación ha de rechazar el replay o hacer que el segundo efecto sea inocuo.

Un reintento automático solo debe seguir a una señal positiva de que la primera solicitud no fue procesada. La encapsulación puede aportar un nonce para detectar repetición. Una fecha puede limitar la ventana, a costa de depender de relojes, tolerancias y almacenamiento. RFC 8470 explica riesgos afines de replay en HTTP temprano, pero no decide qué significa duplicar una orden en esta aplicación.

La vigencia de la configuración de la puerta marca otra frontera temporal. Durante ese periodo OHTTP no ofrece secreto hacia delante frente a la pérdida de su clave privada. Si el adversario conserva tráfico o obtiene colaboración del relé, puede descifrar intercambios históricos. La rotación reduce la ventana; borrar las claves retiradas la cierra. Una copia en una instantánea o en un paquete de soporte mantiene la ventana abierta aunque el panel muestre una clave nueva.

El anonimato tiene una población y una forma

Ambos saltos usan HTTPS obligatoriamente. Aun así, el cifrado deja visibles tamaño, momento, secuencia y fronteras de mensaje. En un servicio masivo, muchos eventos parecidos pueden mezclarse. En uno que recibe dos peticiones por minuto, una petición excepcionalmente grande seguida por una recepción semejante en la puerta puede revelar la pareja.

El padding uniforma tamaños; la demora, el lote y la variación temporal dificultan la coincidencia. Todo cuesta. Más bytes elevan infraestructura y consumo. Más espera empeora la experiencia. La decisión de apagar estas defensas bajo carga cambia la privacidad real y debe dejar un recibo.

La conducta del relé también altera la multitud. Puede retrasar o bloquear selectivamente, dividir tráfico por reputación o enviar ciertos clientes por una ruta rara. Una regla concebida para el abuso puede reducir el anonimato a una cohorte mínima. Por eso hay que medir usuarios activos por configuración, ruta y ventana, no instalaciones acumuladas.

Un indicador sencillo de «petición OHTTP válida» confirma solo la envoltura. El indicador de privacidad pregunta si el evento era distinguible dentro de los demás. Son controles diferentes y ambos necesitan propietario.

Un expediente de separación verificable

La auditoría puede organizarse alrededor de cuatro papeles. Del cliente: código que selecciona la puerta, canal de configuración, campos reales, contexto fresco y reglas de reintento. Del relé: controlador jurídico, cuentas administrativas, metadatos conservados, decisiones diferenciales y ausencia de encabezados identificadores. De la puerta: custodia de claves, texto claro, destinos permitidos, rotación y borrado. Del objetivo: autenticación de la puerta, efecto de replay y registros recibidos.

Después se documentan los puentes: plataforma de observabilidad, proveedor común, equipo de seguridad, copia de soporte, contrato de investigación, sede legal o identificador compartido. Cada puente necesita finalidad, acceso mínimo, caducidad y prueba de destrucción. La independencia no tiene que impedir responder a un incidente, pero una respuesta no debería producir por defecto la tabla completa de usuario y mensaje.

Los ensayos deben comprometer cada papel por separado. Una intrusión en el relé revela orígenes y tiempos; una en la puerta, mensajes y claves; una en la analítica común, posiblemente ambos. Mezclar los tres bajo «incidente de OHTTP» oculta decisiones de contención.

La primacía del código en ejecución de Heng Lu ayuda a mantener la afirmación en su tamaño justo: el sistema divide observaciones mediante funciones ejecutables. No certifica que dos organizaciones no compartan memoria. Su idea de una especificación inicial mínima explica la fuerza de una interfaz pequeña, pero también su condición: la adopción local no puede vaciar la separación que hizo útil el estándar común.

OHTTP ofrece algo mejor que la confianza ciega: una ignorancia diseñada. Christopher A. Wood y Martin Thomson pusieron esa ignorancia en el protocolo. El operador debe demostrar que no la recupera mediante identificadores, registros o excepciones. La prueba final no es un sello criptográfico, sino la imposibilidad práctica de que una sola parte reconstruya quién dijo qué.

Fuentes