Tsunami de CDN: cuando la eficiencia de HTTP/3 se convierte en un amplificador de DDoS

HTTP/3 se creó para hacer que la web sea más rápida y resistente. Al reemplazar TCP con QUIC, reduce la sobrecarga del establecimiento de conexiones, gestiona la pérdida de paquetes de forma más eficiente en flujos simultáneos y es especialmente adecuado para entornos móviles y redes menos fiables. Su mecanismo de compresión de cabeceras QPACK reduce aún más la cantidad de datos que deben viajar a través de la red.

‍

Estas mejoras son significativas y HTTP/3 se está convirtiendo rápidamente en el estándar. Las mediciones de HTTP Archive de junio de 2026 muestran que HTTP/3 es compatible con el 40,7 % de las solicitudes de escritorio y el 42,2 % de las móviles, mientras que W3Techs informa que HTTP/3 está presente en el 40,3 % de los sitios web en agosto de 2026. Sin embargo, Internet no ha hecho la transición a HTTP/3 de manera uniforme. En muchas implementaciones, HTTP/3 termina en una CDN o proxy inverso, mientras que la comunicación con el origen de la aplicación continúa mediante HTTP/1.1 o HTTP/2.

‍

Un artículo publicado recientemente, CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks, muestra por qué esa distinción es importante. Los investigadores demuestran que la diferencia de eficiencia entre los dos lados de una CDN puede convertirse en sí misma en una fuente de amplificación de ataques DDoS. La lección no es que HTTP/3 sea inseguro; más bien, siempre que un intermediario traduce entre protocolos con características de recursos muy diferentes, la frontera de traducción debe formar parte del modelo de seguridad.

‍

HTTP/3 en el borde no significa necesariamente HTTP/3 en el origen

Cuando un navegador establece una conexión HTTP/3 con un sitio web, es fácil imaginar que HTTP/3 continúa hasta el servidor web que aloja la aplicación. Eso es ciertamente posible hoy en día, pero está lejos de ser universal. Una arquitectura de CDN común termina la conexión QUIC del cliente, procesa la solicitud HTTP y crea una conexión separada hacia el origen del cliente utilizando una versión anterior de HTTP.

‍

‍

Cloudflare ofrece una ilustración útil. Su documentación actual sobre HTTP/3 indica que HTTP/3 es compatible entre los usuarios y el borde de Cloudflare, mientras que la conectividad HTTP/3 desde Cloudflare hacia el origen aún no es compatible. Existen buenas razones operativas para este modelo: las CDN pueden implementar nuevos protocolos en sus propias redes de borde sin requerir que los clientes actualicen simultáneamente sus servidores web, pilas de aplicaciones, firewalls y balanceadores de carga.

‍

El compromiso es la asimetría de protocolos. Una solicitud optimizada para una transmisión eficiente a través de HTTP/3 debe reconstruirse eventualmente en una representación diferente antes de poder enviarse a un origen HTTP/1.1. CDN Tsunami demuestra que un atacante puede explotar deliberadamente esta diferencia.

‍

Cuando la compresión se convierte en amplificación de ancho de banda

El primer ataque descrito por los investigadores es la amplificación de ancho de banda de HTTP/3, o HBA. HTTP/3 utiliza QPACK para comprimir las cabeceras HTTP. En lugar de transmitir repetidamente campos de cabecera idénticos o extensos en su totalidad, QPACK permite representarlos de manera más eficiente, incluso haciendo referencia a entradas en una tabla de compresión. En circunstancias normales, esto es exactamente lo que queremos: se transmiten menos bytes mientras se conserva la misma semántica HTTP.

‍

La situación cambia cuando la CDN debe reenviar la solicitud a un servidor HTTP/1.1. HTTP/1.1 no entiende QPACK, por lo que la CDN debe descomprimir y reconstruir esas cabeceras antes de enviarlas hacia el destino. Por lo tanto, la cantidad de datos que llegan del atacante puede ser sustancialmente menor que la cantidad de datos que la CDN transmite finalmente hacia el origen.

‍

‍

Los investigadores midieron ratios de amplificación que oscilaban desde varias decenas de veces utilizando la tabla estática de QPACK hasta aproximadamente 350 veces en experimentos que involucraban su tabla dinámica. En su entorno de pruebas controlado, menos de 500 Kbps de tráfico del atacante pudieron generar suficiente tráfico descendente como para saturar una conexión de origen de 100 Mbps. En lugar de proporcionar todo el ancho de banda del ataque por sí mismos, los atacantes convencen a una CDN para que genere gran parte de él en su nombre.

‍

La eficiencia de la conexión también puede amplificarse

El ancho de banda es solo una forma de consumo de recursos. La segunda técnica de CDN Tsunami, la amplificación de conexión HTTP/3 (HCA), se dirige en cambio a las conexiones de backend. QUIC está diseñado para multiplexar muchas transmisiones HTTP/3 independientes de manera eficiente a través de una sola conexión. Esto evita la sobrecarga asociada con la creación repetida de conexiones TCP y permite que transmisiones no relacionadas progresen de forma independiente cuando se pierden paquetes.

‍

El problema surge cuando esas transmisiones de frontend se asignan de manera ineficiente a conexiones HTTP/1.1 de backend. Un pequeño número de conexiones QUIC que contienen muchas transmisiones puede hacer que una CDN establezca potencialmente un número mucho mayor de conexiones TCP hacia el origen. La investigación descubrió que varias implementaciones probadas comenzaban a asignar conexiones de backend tras recibir las cabeceras de solicitud HTTP/3 en lugar de esperar a que llegara la solicitud completa, lo que permitía a un atacante iniciar muchas transmisiones y luego enviar lentamente los datos restantes.

‍

‍

La amplificación en este caso no se mide en gigabits por segundo. Se mide en tablas de conexión, sockets, trabajadores, memoria y, en última instancia, en el número de usuarios legítimos a los que el origen todavía es capaz de atender. Esto es importante porque los ataques DDoS nunca han sido exclusivamente un problema de ancho de banda; cualquier recurso suficientemente limitado puede convertirse en el objetivo.

‍

La CDN se convierte en el amplificador

Los ataques de amplificación tradicionales suelen seguir un patrón conocido: un atacante envía una pequeña solicitud a un intermediario, como un servicio DNS mal configurado, que luego genera una respuesta mucho mayor hacia la víctima. CDN Tsunami presenta un problema diferente. El intermediario no es un servicio oscuro o expuesto incorrectamente; es una CDN legítima que la víctima ha colocado intencionadamente frente a su aplicación.

‍

Por lo tanto, el tráfico resultante que llega al origen puede parecer legítimo. Proviene de una infraestructura de CDN confiable, utiliza HTTP válido e incluso puede originarse en rangos de IP que el firewall del cliente ha incluido específicamente en su lista de permitidos. En muchas implementaciones de CDN, permitir que solo las direcciones de la CDN lleguen a un origen se considera una buena práctica de seguridad. Eso significa que las preguntas convencionales como "¿De dónde vino este tráfico?" se vuelven menos útiles. Una pregunta más importante es: "¿Cuánto trabajo descendente provocó esta solicitud de frontend aparentemente pequeña?"

‍

‍

La seguridad debe tener en cuenta ambos lados del proxy

La protección contra ataques DDoS en la capa de aplicación se basa tradicionalmente en señales como las tasas de solicitud, las tasas de conexión, la reputación de la fuente, el comportamiento de las URL, las características de la sesión y las desviaciones de los patrones de tráfico establecidos. Aunque todas siguen siendo útiles, la traducción de protocolos introduce otra relación que merece ser supervisada: la amplificación de recursos entre el frontend y el backend.

‍

Una solicitud de 2 KB que llega a un proxy y genera una solicitud de 100 KB hacia el origen no es necesariamente alarmante si se analiza cada lado de forma independiente. Sin embargo, una tasa de expansión de 50 a 1 merece atención. Lo mismo ocurre con las conexiones: una conexión QUIC que transporta decenas o cientos de flujos HTTP/3 puede ser perfectamente normal, pero si esos flujos derivan en conexiones excesivas hacia el backend, el recuento de conexiones del frontend por sí solo ofrece una visión incompleta del riesgo.

‍

Por lo tanto, los proxies modernos y las plataformas de protección de aplicaciones necesitan visibilidad sobre estas proporciones. Los controles relevantes incluyen tamaños máximos de encabezados descomprimidos, límites de QPACK, controles de concurrencia de flujos HTTP/3, restricciones en la expansión de conexiones hacia el backend, validación de solicitudes antes de asignar recursos costosos en el backend, tiempos de espera adecuados para flujos y conexiones, y la detección de proporciones anormales en la conversión de protocolos. A menudo, esto se describe como mitigaciones para HTTP/3, pero el principio más amplio es la gobernanza de recursos: ¿cuánto trabajo en el downstream debería permitirse que genere una unidad de actividad en el upstream?

‍

HTTP/3 no es la vulnerabilidad

Es importante no malinterpretar esta investigación como una crítica al protocolo HTTP/3 en sí. QPACK hace lo que se supone que debe hacer la compresión, QUIC hace lo que se supone que debe hacer la multiplexación, y la capacidad de HTTP/3 para mover más información con menos sobrecarga de conexión y transporte es una funcionalidad, no un defecto.

‍

La vulnerabilidad surge cuando se permite que estas eficiencias se traduzcan en un consumo desproporcionado de recursos en otras partes de la cadena de entrega. Por lo tanto, la solución no es dejar de adoptar protocolos más nuevos. La mejor respuesta es tratar la conversión de protocolos como un límite de seguridad en sí mismo.

‍

La adopción de HTTP/3 está creciendo, pero la transición es desigual

HTTP/3 está ahora lo suficientemente extendido como para que su soporte sea una consideración cada vez más importante para los proveedores de CDN, entrega de aplicaciones y WAAP. Al mismo tiempo, las cifras publicadas sobre la adopción de HTTP/3 no deben confundirse con la proporción de servidores de origen que terminan HTTP/3 de forma nativa. Una cantidad significativa del tráfico HTTP/3 actual termina en infraestructuras orientadas a Internet operadas por CDN y proxies inversos, mientras que las aplicaciones detrás de ese borde siguen ejecutándose en una mezcla de servidores compatibles con HTTP/1.1, HTTP/2 y, cada vez más, HTTP/3.

‍

Es poco probable que este entorno heterogéneo desaparezca pronto. Las empresas reemplazan su infraestructura de backend mucho más lentamente de lo que los navegadores y las redes de borde a hiperescala adoptan nuevas tecnologías de transporte. Por lo tanto, la traducción de protocolos seguirá siendo una parte normal de la arquitectura de Internet en el futuro previsible. La pregunta para los proveedores de seguridad no es si la traducción debería existir, sino si sus implicaciones en los recursos se comprenden y limitan adecuadamente.

‍

Un enfoque medido para HTTP/3

El servicio de Protección de Aplicaciones de Nexusguard no termina actualmente las conexiones HTTP/3 del lado del cliente. En su lugar, los clientes negocian una versión de HTTP compatible, incluido HTTP/2. En consecuencia, la ruta de conversión específica de HTTP/3 a HTTP/1.1 explotada por CDN Tsunami no está presente en nuestra arquitectura actual de Protección de Aplicaciones.

‍

Esto no debe interpretarse como un argumento en contra de HTTP/3. Las ventajas de rendimiento de QUIC y HTTP/3 son evidentes, y seguimos evaluando la compatibilidad con HTTP/3. Sin embargo, implementarlo de forma segura requiere algo más que habilitar QUIC en el frontend y traducir las solicitudes a un protocolo de backend existente. La investigación sobre CDN Tsunami refuerza la necesidad de considerar la expansión de encabezados descomprimidos, la concurrencia de flujos, la asignación de conexiones de backend, la distribución de frontend a backend y las tasas de amplificación de recursos como parte del diseño mismo.

‍

También existe una distinción importante entre proteger el tráfico QUIC y proporcionar protección a nivel de aplicación HTTP/3. Los sistemas DDoS de capa de red pueden detectar y mitigar muchos ataques volumétricos y de nivel de transporte que involucran UDP y QUIC sin necesidad de terminar la sesión HTTP/3. No obstante, comprender las solicitudes HTTP, el comportamiento de QPACK y la semántica de los flujos de la capa de aplicación requiere un nivel más profundo de conocimiento sobre HTTP/3. A medida que aumente su adopción, ambas capacidades serán cada vez más importantes.

‍

La lección más importante de CDN Tsunami

La infraestructura de Internet siempre ha evolucionado volviéndose más eficiente. La compresión reduce el ancho de banda, la multiplexación reduce la sobrecarga de las conexiones, las conexiones persistentes reducen las reiteradas negociaciones (handshakes) y el almacenamiento en caché reduce la carga de trabajo del origen. Cada generación permite realizar más trabajo útil con menos recursos. Los atacantes observan estas mismas eficiencias desde la dirección opuesta: buscan situaciones en las que una pequeña cantidad de su propio esfuerzo pueda hacer que la infraestructura de otra persona realice una cantidad desproporcionada de trabajo.

‍

CDN Tsunami es un ejemplo especialmente interesante porque ninguna de las tecnologías individuales necesita estar fundamentalmente rota. HTTP/3 puede funcionar correctamente, QPACK puede funcionar correctamente, HTTP/1.1 puede funcionar correctamente y la CDN puede realizar la traducción entre ellos con éxito. Sin embargo, la relación entre estos componentes que funcionan correctamente aún puede crear una oportunidad de amplificación.

‍

Quizás esa sea la lección más amplia para la defensa contra DDoS. Proteger la infraestructura moderna requiere cada vez más no solo buscar paquetes maliciosos o solicitudes excesivas, sino también asimetrías en la forma en que el trabajo se mueve a través de un sistema. Siempre que se pueda hacer que un intermediario realice sustancialmente más trabajo que la parte que se lo solicita, los atacantes tienen una ventaja potencial. A medida que los protocolos se vuelven más eficientes y la infraestructura más interconectada, comprender esos límites ocultos de amplificación puede resultar tan importante como medir el tráfico en sí.

‍

Fuentes

‍Documento de investigación sobre CDN Tsunami — arXiv, 29 de julio de 2026

‍RFC 9114 — HTTP/3

‍Documentación de HTTP/3 de Cloudflare — compatibilidad de usuario a borde y limitación de origen

‍HTTP Archive — Estado de la Web, compatibilidad con HTTP/3

‍W3Techs: estadísticas de uso de HTTP/3, agosto de 2026