HTTP/2 Rapid Reset expõe nova escala de DDoS

O HTTP/2 Rapid Reset colocou a camada de aplicação no centro de uma nova discussão sobre DDoS. Cloudflare, Google e AWS coordenaram a divulgação de uma técnica que abusa de um comportamento legítimo do HTTP/2: abrir streams, enviar requisições e cancelá-las rapidamente com RST_STREAM, criando pressão desproporcional sobre servidores, proxies e balanceadores.¹

A gravidade vem da relação entre custo para o atacante e custo para a infraestrutura atacada. A Cloudflare afirma ter observado ataques que chegaram a pouco mais de 201 milhões de requisições por segundo. O Google relata pico superior a 398 milhões de requisições por segundo em ataques contra serviços do Google e clientes do Google Cloud.²

O problema nasce de uma otimização útil

HTTP/2 foi desenhado para multiplexar muitas requisições em uma única conexão. Essa característica melhora uso de rede e reduz limitações clássicas do HTTP/1.1, mas também cria um espaço operacional delicado: o servidor precisa aceitar, classificar, encaminhar e encerrar streams de forma muito rápida.

O cancelamento com RST_STREAM é necessário para navegadores e clientes reais. Uma imagem que sai da área visível, uma navegação interrompida ou uma busca substituída por outra podem cancelar trabalho em andamento. O protocolo permite isso sem derrubar a conexão inteira, o que normalmente economiza recursos.

No Rapid Reset, a mesma mecânica é usada de modo agressivo. O cliente envia uma sequência de requisições e as cancela antes que o servidor consiga estabilizar o trabalho associado. Como o stream sai rapidamente do limite de concorrência, o atacante pode continuar abrindo novos streams sem esperar respostas. O limite de streams simultâneos, sozinho, deixa de ser defesa suficiente.

Proxies e origens sentem pressões diferentes

Arquiteturas modernas costumam terminar HTTP/2 em proxies reversos, CDNs, gateways de API ou load balancers. Essa camada recebe frames, aplica políticas e encaminha trabalho para serviços internos. Quando o volume de requisições canceladas cresce demais, o gargalo pode aparecer antes da aplicação final, em filas, buffers, comunicação com upstreams, geração de logs ou módulos de segurança.

Esse detalhe é relevante para times de infraestrutura. Um serviço pode parecer protegido por autoscaling e limites de aplicação, mas ainda depender de componentes que precisam gastar CPU para reconhecer e descartar tráfego malicioso. DDoS em camada 7 não é apenas largura de banda; é exaustão de caminhos de processamento.

A resposta exige proteção perto da borda. Mitigações citadas pelas empresas passam por detecção de padrões de reset, encerramento de conexões abusivas, ajustes em proxies HTTP/2, rate limiting contextual e capacidade de absorção distribuída. Para serviços expostos diretamente, a recomendação prática é revisar servidores, bibliotecas e appliances que implementam HTTP/2.

A lição para operação é menos confortável

CVE-2023-44487 mostra que protocolos maduros também carregam riscos emergentes quando usados em escala extrema. O ponto não é abandonar HTTP/2, e sim reconhecer que eficiência e abuso costumam morar no mesmo recurso. Multiplexação, cancelamento barato e alto paralelismo são bons para a web normal e atraentes para tráfego hostil.

Equipes que operam APIs públicas, e-commerce, SaaS e plataformas de login precisam tratar a divulgação como um alerta de arquitetura. Vale confirmar patches de fornecedores, testar comportamento de gateways, observar métricas por conexão, revisar limites de requisição e simular degradação. Quando um ataque consegue concentrar centenas de milhões de requisições por segundo, a defesa precisa combinar protocolo, borda, observabilidade e resposta operacional.