Resumen

  • Rapid Reset abría una petición HTTP/2 y la cancelaba de inmediato, liberando el cupo formal aunque el proxy o el servicio posterior siguieran consumiendo recursos.
  • La defensa duradera juzga la conexión completa, termina pronto el patrón abusivo y protege las colas sin quitar a los clientes normales el derecho a cancelar.

Cerrado en el protocolo, pendiente en la infraestructura

HTTP/2 reúne muchos intercambios independientes dentro de una sola conexión. Un navegador descarga recursos en paralelo sin repetir TCP y TLS. El servidor anuncia mediante SETTINGS_MAX_CONCURRENT_STREAMS cuántos flujos puede mantener activos el otro extremo.

Solo cuentan los flujos abiertos o semicerrados. RST_STREAM lleva uno al estado cerrado y devuelve su plaza. La regla sirve a usuarios reales: alguien navega a otra página, vence un plazo o una aplicación deja de necesitar una respuesta.

Rapid Reset explotó la distancia entre el estado lógico y el coste físico. El atacante enviaba HEADERS y acto seguido el reset. El contador borraba el flujo, mientras el receptor quizá ya había reservado memoria, descomprimido cabeceras, cargado una política, elegido un destino o enviado trabajo aguas arriba.

En una arquitectura de proxy inverso, cancelar localmente no garantiza que el trabajo posterior desaparezca. La conexión atacante recuperaba plaza casi sin coste; la infraestructura asumía creación, despacho, aviso y limpieza. No hubo una falsificación, una rotura de TLS ni un exceso estable sobre el límite concurrente. Hubo reutilización acelerada de una plaza formalmente libre.

Google explicó que así el ritmo dejó de depender principalmente del tiempo de ida y vuelta y pasó a depender del ancho de banda. La cortesía de cancelar se convirtió en una técnica para iniciar trabajo sin esperar su resultado.

Las cifras describen superficies distintas

Google, Cloudflare y AWS detectaron la campaña a finales de agosto de 2023 y coordinaron la divulgación con implementadores. El 10 de octubre se publicó CVE-2023-44487.

Google comunicó más de 398 millones de peticiones por segundo. Cloudflare observó un episodio por encima de 201 millones con unas 20.000 máquinas. AWS informó de un pico de CloudFront superior a 155 millones el 28 y 29 de agosto.

No son tres mediciones de la misma secuencia ni deben sumarse. Cada proveedor observó su red, clientes y telemetría. Las cifras demuestran la escala alcanzable, no un requisito universal de capacidad.

Google afirmó que detuvo su mayor ataque en el borde sin producir una caída. Cloudflare registró impacto inicial en torno al uno por ciento de las peticiones, con breves picos cercanos al doce por ciento en los centros más afectados. Son resultados arquitectónicos distintos, no versiones incompatibles del mismo hecho.

La concurrencia protegía otra cosa

El máximo concurrente limita un inventario simultáneo. Rapid Reset generaba trabajo secuencial a enorme velocidad. Cada flujo nacía, ocupaba una plaza, se cancelaba y salía del inventario, aunque su coste sobreviviera.

Reducir ese máximo no resolvía por sí solo el problema. Cloudflare lo bajó a 64 y descubrió que clientes legítimos iniciaban habitualmente hasta 100 flujos antes de recibir los SETTINGS del servidor. Los flujos sobrantes fueron reseteados por el servidor. Una defensa antigua que contaba esos resets interpretó la situación como abuso y cerró conexiones normales. Algunas páginas no cargaron. Cloudflare volvió a 100.

La lección no es que 64 sea inseguro y 100 seguro. Una cifra correcta en aislamiento puede fallar contra el comportamiento desplegado. El límite útil es el que contiene el coste antes de la saturación y ha sido probado con clientes reales.

La conexión se convirtió en unidad de decisión

Google sostuvo que bloquear peticiones una a una no bastaba. El servidor debe observar cuántos flujos abre una conexión, cuántos cancela, cuánto trabajo útil produce y con qué frecuencia infringe límites. Cuando la relación se vuelve abusiva, puede enviar un GOAWAY restrictivo o cerrar el transporte inmediatamente.

El cliente conserva la facultad de retirar una petición. No adquiere por ello un derecho incondicional a mantener la conexión después de convertir las cancelaciones en carga ilimitada. Quien opera la máquina decide si sigue aceptando trabajo.

Cloudflare incorporó los resets enviados por clientes a sus detectores, mejoró el procesamiento de tramas, la propagación de cancelaciones, las colas y la planificación, y adelantó la defensa al proxy TLS. También reforzó los registros por conexión: algunos errores 502 ocurrían antes del proxy que alimentaba la analítica de clientes y quedaban invisibles en el panel normal.

Google, Cloudflare y AWS no tuvieron que usar el mismo número. Coincidieron en algo más importante: la implementación que soporta el coste debe limitarlo localmente y antes de que una cola compartida quede ocupada.

La norma cerraba el flujo, no la deuda

RFC 9113 define multiplexación, concurrencia, RST_STREAM y GOAWAY. Su máquina de estados permite que programas independientes se entiendan. También establece que el flujo reseteado queda cerrado y deja de contar.

Ninguna transición borra el trabajo ya despachado. Un Internet-Draft individual de 2023 describió el hueco y propuso crédito acumulativo para la creación de flujos. Es una señal técnica útil, no una norma aprobada ni consenso del IETF.

La especificación inicial mínima de Heng Lu separa funciones. El contrato común mantiene las tramas y la cancelación legítima. La decisión futura sobre recursos queda en el extremo que paga. Varias implementaciones pueden demostrar límites seguros mediante código operativo antes de convertir una práctica concreta en regla común.

El inventario que importa

«HTTP/2 habilitado» no mide exposición. «Parche aplicado» no demuestra continuidad. Hay que localizar cada terminación: CDN, balanceador, ingress, malla, proxy y aplicación; saber dónde se reserva el primer recurso caro y hasta dónde viaja la cancelación.

El registro debe contener versión exacta, origen del parche, presupuesto por conexión, colas compartidas y telemetría. La prueba combina navegación ordinaria, cancelaciones legítimas y secuencias hostiles. Las peticiones normales deben avanzar, la conexión atacante debe terminar y el motivo debe aparecer en los datos.

Desactivar HTTP/2 puede contener una emergencia sin actualización disponible. Necesita propietario, alcance, vencimiento y prueba de regreso. Si no, una excepción temporal oculta que nunca se arregló la contabilidad del trabajo.

Límites de la evidencia

Las fuentes no identifican todos los objetivos ni pérdidas. Los máximos no son ensayos comparables. La resistencia de un gran borde no predice la de un servidor sin protección, y publicar una versión corregida no prueba su despliegue inmediato en cada distribución.

La conclusión firme es más precisa: cerrar un objeto de protocolo no equivale a recuperar el trabajo que inició. El receptor debe poder terminar la relación cuando la corrección formal se convierte en abuso de recursos.

Fuentes