Conformidad HTTP vs. Middleboxes: Identificar dónde se rompen las reglas

Tradicionalmente, las comunicaciones en red siguen un enfoque por capas, en el que los protocolos de la capa de aplicación, como el Protocolo de Transferencia de Hipertexto (HTTP), están pensados para funcionar de extremo a extremo. Estos protocolos y funciones deben cumplir las normas acordadas (RFC) establecidas por el Grupo de Trabajo de Ingeniería de Internet (IETF).

En la práctica, la comunicación de extremo a extremo a menudo se ve interrumpida por middleboxes,dispositivos intermediosy proxies que mejoran la seguridad y el rendimiento. Un cortafuegos es un ejemplo de middlebox, que bloquea el acceso no autorizado a una red interna, protegiendo a los usuarios de las amenazas externas. Más información sobre las middleboxes.

Comprender cómo afectan estas y otras middleboxes a las cadenas de procesamiento de las comunicaciones y sus correspondientes RFC es esencial para identificar los posibles riesgos para la seguridad.

Mis colegas, Mahmoud Attia y Marc Dacier, y yo tratamos recientemente de examinar cómo los proxies, un tipo común de middlebox (figura 1), repercuten en la conformidad HTTP/1.1 tal y como se define en sus correspondientes RFC (véase el artículo).

Identificamos 47 normas a nivel de requisitos y comprobamos su cumplimiento en doce proxies populares, incluidas cuatro redes de distribución de contenidos (CDN), componentes clave de la infraestructura que mejoran el rendimiento y la seguridad de la web. Nuestros hallazgos revelaron tres comportamientos distintos, a saber, algunos proxies:

1. Descarte los paquetes no conformes.
2. Reenvía los paquetes no conformes tal cual.
3. Modifique los paquetes no conformes en conformes.

Nuestros resultados indican que todos los proxies se comportaron de forma similar en 7 de nuestros 47 casos de prueba. Los proxies muestran comportamientos muy incoherentes en los 40 casos de prueba restantes, dejando al descubierto ambigüedades en las interpretaciones de las RFC (Figura 3).

Además, ninguno de los proxies siguió una política uniforme para tratar los datos no conformes. Por ejemplo, Cloudflare, una CDN líder, modificó paquetes en 17 casos de prueba, los reenvió sin cambios en 20 casos y rechazó paquetes no conformes en 10 casos.

Además, los proxies demostraron incoherencias entre la gestión de las solicitudes de los clientes y las respuestas de los servidores. La RFC 9112 ordena rechazar o sanear los mensajes que contengan caracteres no válidos (CR, LF o NUL). Mientras que todos los proxies rechazaron tales mensajes de cliente a servidor, cinco proxies modificaron las respuestas de servidor a cliente, mientras que siete proxies las reenviaron sin cambios.

Nuestro estudio identifica dos problemas significativos con las RFC HTTP/1.1:

1. Terminología inadecuada
2. Falta de exhaustividad

Las RFC HTTP/1.1 especifican a veces requisitos claros para "clientes" y "servidores" pero dejan ambiguos los "proxies".

Esto permite a los desarrolladores implementar proxies como mejor les parezca, pero esta flexibilidad también introduce vulnerabilidades potenciales, como el contrabando de peticiones.

Recomendamos que las RFC proporcionen directrices claras y rigurosas a clientes, servidores e intermediarios para mitigar estos problemas. Las normas deberían definir explícitamente cómo deben manejar los proxies los datos no conformes, por ejemplo rechazando las solicitudes malformadas como comportamiento por defecto.

De cara al futuro, nuestro objetivo es investigar las reglas a nivel de recomendación además de las reglas a nivel de requisito, analizar las versiones HTTP más recientes (HTTP/2 y HTTP/3) -que introducen una mayor complejidad y optimizaciones- y seguir explorando el impacto de las especificaciones RFC y los middleboxes en la conformidad del protocolo. Abordar estas cuestiones contribuirá a lograr implementaciones HTTP más seguras en toda la web.

Ilies Benhabbour es estudiante de doctorado y trabaja bajo la supervisión del profesor Marc Dacier en la KAUST. Su investigación se centra en los problemas derivados de la existencia de middleboxes de red.

Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.