Privacidad en internet con Oblivious HTTP
A los internautas cada vez les preocupa más quién recopila su información personal y cómo puede utilizarse para retratar su vida online (o real). Sin embargo, la mayoría de la gente quiere disfrutar de la comodidad y utilidad de sus aplicaciones web y móviles, y se resiste a renunciar a todo eso para vivir aislada de internet en nombre de la privacidad.
Las empresas que prestan estos servicios de internet no lo tienen nada fácil a la hora de equilibrar los intereses contrapuestos en torno a la utilidad del producto y el mantenimiento de la privacidad. El mero hecho de recibir datos de los usuarios finales durante la prestación normal de un servicio puede someter a las empresas a una presión normativa y unos requisitos de cumplimiento considerables, y esta presión aumenta a medida que el servicio va teniendo más éxito.
Fastly es un proveedor de servicios de distribución en el edge en el que confían algunas de las mayores empresas de internet, y seguimos ofreciendo a nuestros clientes nuevos productos y tecnologías para ayudarles a ampliar sus servicios sin sacrificar la privacidad de los usuarios. Nos alegra anunciar el último de nuestros productos para mejorar la privacidad: OHTTP Relay de Fastly, ya disponible en la versión beta para determinados partners. El OHTTP Relay de Fastly es un componente de la arquitectura Oblivious HTTP que te permite recibir datos de peticiones esenciales de tus usuarios finales sin metadatos identificativos que no necesitas.
HTTP no nació pensando en la privacidad
El simple hecho de recibir una petición HTTP de un usuario final, aunque no tenga ningún tipo de encabezado especial ni detalles identificativos en el cuerpo de la petición, proporciona automáticamente metadatos que pueden utilizarse para identificar de manera inequívoca a una persona real o para acotar su identidad online. Los detalles del navegador en encabezados como User-Agent y Accept y los datos de la red que ofrecen los sistemas autónomos (AS) y las direcciones IP se pueden combinar</u> para desvelar la identidad de un usuario final. Aunque esos metadatos de la petición no se registren ni se envíen a un almacén de datos, los envía el usuario final y los recibe el origen del servicio, y resulta muy sencillo empezar a registrarlos más adelante. En última instancia, lo que se pide al cliente es que confíe en que custodiarás correctamente su información, pero que también lo hará cualquier organización o entidad gubernamental que herede los datos que hayas recopilado y que quizá no se rija por tus mismos principios.
Es posible rediseñar un servicio HTTP ya existente para garantizar la privacidad, pero es habitual que carezca de estandarización y de una metodología aplicable, lo que conlleva un trabajo extra de ingeniería tanto para crear el servicio como para mantenerlo, con el riesgo añadido de que pueden producirse fugas accidentales de información delicada. Esto, además, obliga al proveedor del servicio HTTP a explicar al cliente y a los demás agentes del sector cómo protege la privacidad, con el fin de garantizar que se ajusta a lo previsto.
Para superar estos obstáculos conviene disponer de un mecanismo estandarizado que permita enviar peticiones HTTP a los puntos de conexión de las API, preservando al mismo tiempo la privacidad del usuario final. El nuevo estándar Oblivious HTTP</u> es un mecanismo que puede utilizarse en una gran variedad de casos de uso con API y que permite crear servicios repetibles, plenamente probados y bien definidos. Aunque todavía se encuentra en fase de desarrollo, parece muy prometedora como tecnología clave para crear servicios de internet que protejan la privacidad.
¿En qué consiste OHTTP y cómo funciona?
Oblivious HTTP (OHTTP) es tanto una especificación para transmitir mensajes como una arquitectura de servicios de alto nivel. Esta combinación permite a un proveedor de servicios HTTP recibir mensajes de un cliente HTTP especial en un origen HTTP estándar sin tener que recibir también metadatos de peticiones y de red innecesarios y no solicitados. La doble ocultación del servicio OHTTP es esencial para garantizar la privacidad del usuario: mientras una capa gestiona los metadatos que identifican al usuario final (el relé), la otra se ocupa de los datos de la petición del usuario final (la puerta de enlace). Ambas capas se comunican, pero no colaboran.
La arquitectura OHTTP tiene cuatro capas:
1. El cliente OHTTP
El cliente OHTTP es un cliente HTTP especial que encapsula y cifra una petición HTTP dirigida al destino OHTTP y la envía al relé OHTTP. En su revisión actual, los clientes OHTTP son adecuados para comunicarse con servicios OHTTP específicos, preconfigurados y conocidos, ya que la clave de cifrado y los formatos de petición encapsulada son exclusivos de un servicio determinado y deben conocerse de antemano.
2. El relé OHTTP
El relé OHTTP es el primero de los dos servicios que constituyen el núcleo de doble ocultación de la arquitectura OHTTP.
Recibe la petición encapsulada directamente del cliente OHTTP, junto con los encabezados de la petición HTTP estándar y la información de conexión de red correspondiente, por lo que conoce detalles de identificación del cliente, que elimina antes de enviar la petición a la puerta de enlace OHTTP.
Como la petición encapsulada está cifrada con una clave que no posee, el relé OHTTP no sabe qué datos ha enviado el cliente al destino.
3. La puerta de enlace OHTTP
La puerta de enlace OHTTP es el segundo de los servicios que conforman el núcleo de doble ocultación de la arquitectura OHTTP.
Recibe la versión privatizada de la petición del cliente desde el relé OHTTP, y descifra y desencapsula la petición interna, para luego reenviarla al destino OHTTP.
Dado que la petición externa se ha privatizado, la puerta de enlace OHTTP ignora los metadatos de identificación del cliente.
4. El destino OHTTP
El destino OHTTP es un servicio HTTP estándar que recibe la petición encapsulada original del cliente en un formato sin encapsular, que funciona como una petición HTTP típica. No posee ninguna información de identificación sobre el cliente o usuario final, excepto los encabezados de la petición HTTP permitidos a través del relé OHTTP y los datos que el cliente OHTTP haya insertado en la petición encapsulada.
El destino OHTTP procesa esta petición, por ejemplo, proporcionando una respuesta de la API JSON al cliente (sin haber recibido ni procesado información de identificación sobre el cliente), que luego la puerta de enlace encapsula y reenvía a través del stack de servicios OHTTP.
¿De qué manera me ayuda Fastly a ofrecer un servicio habilitado para OHTTP?
Desde el punto de vista técnico, el proveedor de servicios HTTP puede implementar y utilizar todas las capas de la arquitectura OHTTP (cliente, relé, puerta de enlace y destino). Todos los componentes funcionan de forma coordinada para ofrecer el servicio habilitado para OHTTP, por lo que es lógico utilizarlos juntos. A priori, utilizar OHTTP de este modo garantizaría la protección de la privacidad, pero si una misma entidad gestionara conjuntamente los dos servicios OHTTP de doble ocultación (el relé y la puerta de enlace OHTTP), se pondría en riesgo la capacidad de OHTTP de protección de la privacidad. Esto no solo genera un riesgo de pérdida de confianza, sino que el mero hecho de que parezca que se ha perdido la confianza acaba siendo la peor de las pesadillas para los servicios de protección de la privacidad.
Aunque la ruta esencial de la petición seguiría siendo privada, el operador podría realizar fácilmente operaciones de canal lateral para combinar la información que solo el relé conoce (metadatos de la petición del cliente y detalles de la red) con la que solo la puerta de enlace conoce (el cuerpo de la petición encapsulada) y, de este modo, lograr eludir la protección de la privacidad que ofrece la arquitectura OHTTP.
La mera existencia de esta posibilidad, a falta de los pasos reales para implementarla, sirve para erosionar la confianza del usuario en el proveedor y en el servicio habilitado para OHTTP. En última instancia, el usuario final debe poder confiar tanto en que la especificación OHTTP está bien diseñada como en que el proveedor ha implementado su arquitectura de forma que cumpla efectivamente la promesa de mantener la privacidad.
Por tanto, lo ideal no es que el propio proveedor de servicios HTTP despliegue el relé OHTTP, sino que recurra a un partner de confianza con una sólida reputación en la prestación de servicios de alta disponibilidad a través de una infraestructura segura y escalable. Fastly es un partner idóneo para los clientes que quieren crear servicios que preserven la privacidad y mejoren la experiencia de uso en internet.
OHTTP Relay de Fastly
Fastly ha creado un servicio OHTTP Relay que aprovecha nuestra plataforma global de edge computing para facilitar una rápida escalabilidad y así cubrir todas las necesidades de tus servicios. Podemos ayudarte en multitud de casos de uso de OHTTP, como los siguientes:
Una aplicación móvil que envía periódicamente registros de fallos a un punto de conexión de API; a menudo insensible a la latencia y con mayores cargas útiles.
Un navegador web que valida las peticiones de los clientes con una API de ciberdelincuentes antes de permitir que se establezca la conexión; muy sensible a la latencia, con cargas útiles muy pequeñas.
La posibilidad de ir más allá de la especificación OHTTP básica y ofrecer una lógica de servicio personalizada, como la distribución de registros anonimizados, la autenticación de tokens, etc.
Nuestro primer servicio habilitado para OHTTP es el servicio FLEDGE</u> de Google Chrome, que en su lanzamiento utilizará exclusivamente OHTTP Relay de Fastly para permitir el envío con k-anonimato</u> de publicidad comportamental sin usar cookies de terceros. Al prestar este servicio, Fastly:
Recibe peticiones OHTTP de los clientes de Google Chrome.
Lleva a cabo determinadas validaciones para garantizar que son peticiones OHTTP reales.
Elimina todos los encabezados HTTP no incluidos en la lista de permitidos (en principio, Content-Type, Content-Length y Host).
Pasa la petición a los backends de Google definidos de forma explícita.
Además, solo se facilitan a Google las métricas de nivel de servicio. Google no tiene acceso a la configuración del servicio OHTTP Relay ni a la visualización de la información sin procesar de las peticiones (como los registros de peticiones).
Cara al futuro
El servicio OHTTP Relay de Fastly ya está disponible en versión beta. Si estás desarrollando servicios de internet que garanticen la privacidad o te lo estás planteando, nos encantaría hablar contigo sobre cómo Fastly puede ayudarte a desarrollar, utilizar y ampliar estos servicios para garantizar que el respeto a la privacidad de los usuarios sea lo más estricto posible y, al mismo tiempo, ofrecer la mejor experiencia.
