Resumo

  • No Rapid Reset, o cliente abria um fluxo HTTP/2 e enviava RST_STREAM quase de imediato. O fluxo deixava de contar para a concorrência, mas o proxy ou a aplicação podia continuar processando o pedido.
  • A defesa mais eficaz passou a julgar o comportamento acumulado da conexão: detectar ciclos anormais, enviar GOAWAY ou fechar o canal, sem destruir o cancelamento legítimo para todos.

Fechado no protocolo, vivo na máquina

HTTP/2 permite multiplexar muitos pedidos em uma única conexão. Também permite cancelar um fluxo com RST_STREAM: uma função necessária quando o usuário abandona uma página, uma busca se torna irrelevante ou uma aplicação já obteve o resultado de que precisava. A vulnerabilidade registrada como CVE-2023-44487 nasceu da combinação dessas duas capacidades, não de uma extensão obscura.

O padrão limita a quantidade de fluxos ativos simultâneos. Um fluxo encerrado, porém, deixa de ocupar esse orçamento. O cliente ofensivo podia enviar HEADERS, disparar o pedido e, em seguida, resetar o fluxo. A vaga era liberada imediatamente, permitindo repetir o ciclo dentro da mesma conexão. Para a camada de protocolo, a operação parecia concluída. Para o servidor, o roteamento, a descompressão, o registro, a consulta ou o trabalho no backend talvez apenas tivesse começado.

A dívida real, portanto, não aparecia no número de fluxos abertos. Ela estava no trabalho iniciado e ainda não recuperado. O Rapid Reset fez dessa distância um multiplicador: uma conexão podia criar pedidos mais depressa do que a infraestrutura conseguia cancelar ou concluir.

Três picos, três pontos de observação

As divulgações de 2023 mostraram o tamanho da pressão, mas os números precisam permanecer separados. O Google informou um ataque acima de 398 milhões de requisições por segundo. A Cloudflare relatou pico acima de 201 milhões de requisições por segundo, originado de uma botnet estimada em cerca de 20 mil máquinas. A AWS descreveu eventos acima de 155 milhões de requisições por segundo em 28 e 29 de agosto.

Esses valores não formam um único ataque somável. Cada provedor mediu eventos e superfícies próprias. O dado comparável é a mudança de ordem de grandeza: o método aumentou a eficiência por máquina comprometida porque reutilizava conexões e explorava uma contabilização que esquecia o trabalho cedo demais.

Também seria incorreto concluir que toda implementação HTTP/2 sofreu da mesma maneira. Arquiteturas, proxies, filas, políticas de cancelamento e limites eram diferentes. O episódio foi global em relevância, mas local em mecanismo e correção.

O orçamento errado

Um limite de concorrência responde a uma pergunta simples: quantos fluxos estão ativos agora? O Rapid Reset exigiu perguntas mais duras: quantos pedidos esta conexão iniciou, quantos cancelou, quanto trabalho sobreviveu ao cancelamento e com que rapidez os recursos voltaram ao sistema?

Reduzir MAX_CONCURRENT_STREAMS parecia uma reação direta. A experiência da Cloudflare mostrou o perigo de tratá-la como solução universal. Ao reduzir o valor anunciado para 64, a empresa encontrou clientes legítimos que assumiam otimisticamente 100 fluxos antes de receber as configurações do servidor. Os resets emitidos pelo servidor para o excesso interagiram com proteções anteriores baseadas na contagem de resets e produziram falhas de página. O limite voltou a 100.

O episódio não invalida limites de concorrência. Mostra que um único número não representa todo o custo e que uma mudança defensiva pode colidir com comportamento real já existente. O teste decisivo é em execução: a política preserva tráfego normal enquanto impede uma conexão de renovar trabalho sem pagar pelo anterior?

A conexão como unidade de responsabilidade

O Google descreveu uma resposta centrada em detectar rapidamente o padrão no nível da conexão e então emitir GOAWAY ou fechar o canal. A Cloudflare acrescentou detecção de resets do cliente e registrou trabalho em filas, agendamento, cancelamento e telemetria, além de mitigação anterior em seu proxy TLS. O ponto comum é mais importante que a implementação: um reset individual pode ser válido; uma sequência acumulada pode provar abuso.

Fechar a conexão muda a economia. O atacante perde o canal que tornava barato abrir e apagar fluxos. Reconectar exige novo estado e oferece outra oportunidade de classificação. O usuário normal continua podendo cancelar pedidos ocasionais. A defesa não proíbe a função; retira a licença de repeti-la sem limite quando o trabalho sobrevivente cresce.

Isso segue a primazia do código em execução. O protocolo fornece estados compartilhados, mas é a implementação que possui filas, CPU, memória e dependências. Logo, ela precisa conservar autoridade local para terminar uma conexão cujo comportamento ameaça esses recursos.

O que o padrão disse — e o que não disse

A RFC 9113 define estados de fluxo, RST_STREAM, GOAWAY e o limite de concorrência. Ela dá aos pares uma linguagem comum para coordenar encerramento e erro. Não promete que todo efeito interno desapareça no instante em que um quadro de reset chega. Esse efeito depende do caminho concreto entre borda, proxy, serviço e banco de dados.

Um rascunho individual apresentado posteriormente propôs créditos cumulativos de fluxos, de modo que a criação contínua tivesse orçamento mesmo quando os fluxos fossem fechados rapidamente. A proposta é útil como diagnóstico: a vida inteira da conexão precisa entrar na conta. Mas ela não deve ser descrita como padrão aprovado ou consenso do IETF. É uma possibilidade de desenho, não uma regra universal.

A especificação mínima deve continuar definindo semântica interoperável. A implementação local deve medir custo e decidir quando a cooperação deixou de ser segura. Misturar essas camadas cria dois erros opostos: esperar que o padrão controle filas que não enxerga ou introduzir defesas locais que quebram clientes legítimos sem observação suficiente.

O inventário que importa

Uma organização não prova correção dizendo apenas que “aplicou o patch”. Precisa identificar onde HTTP/2 termina, onde o pedido é encaminhado e em qual ponto um cancelamento realmente interrompe trabalho. Um balanceador atualizado não basta se um proxy interno ou serviço de aplicação continua aceitando dívida sem limite.

O inventário útil liga cada terminação HTTP/2 a cinco fatos: política de versão, taxa acumulada de fluxos, razão entre aberturas e resets, trabalho que permanece após o reset e autoridade capaz de encerrar a conexão. Testes devem reproduzir tráfego legítimo com cancelamento, não só o padrão ofensivo. Caso contrário, a defesa pode parecer forte porque derruba ambos.

Limites da evidência

Os relatos públicos vêm principalmente de grandes provedores que observaram e mitigaram seus próprios eventos. Eles sustentam o mecanismo, os picos reportados e várias respostas operacionais. Não permitem estimar a fração de toda a internet que esteve vulnerável, nem provar que uma única política serve para todos. Também não tornam o cancelamento malicioso por natureza.

O resultado mais sólido é estreito: encerrar um objeto protocolar não garante que seu custo foi recuperado. Sistemas multiplexados precisam contabilizar a dívida ao longo do canal que a produz.

Fontes

  1. Cloudflare, “HTTP/2 Rapid Reset: deconstructing the record-breaking attack”: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
  2. Google Cloud, “How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack”: https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack?hl=en
  3. Google Cloud, “Google mitigated the largest DDoS attack to date”: https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps
  4. AWS Security Blog, “How AWS protects customers from DDoS events”: https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/
  5. AWS Security Bulletin AWS-2023-011: https://aws.amazon.com/security/security-bulletins/AWS-2023-011/
  6. IETF, RFC 9113, “HTTP/2”: https://www.rfc-editor.org/rfc/rfc9113.html
  7. IETF Internet-Draft, “Cumulative Stream Limits for HTTP/2”: https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
  8. Heng Lu, “Running-Code Primary”: https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  9. Heng Lu, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”: https://heng.lu/minimum-initial-specification-localized-future-decision-and-voluntary-adoption-for-internet-coordination-systems/