Resumo

  • O HTTP/2 Rapid Reset transformou uma operação prevista pelo protocolo — abrir e cancelar streams — em um mecanismo de negação de serviço quando o trabalho produzido no servidor era desproporcional ao custo para o cliente.
  • A resposta passou por divulgação coordenada, revisão no ecossistema HTTP, correções específicas de implementação e controles de operador. Nenhuma dessas etapas, isoladamente, demonstra que todos os sistemas afetados foram corrigidos.

O mecanismo estava dentro de uma fronteira legítima do protocolo

O HTTP/2 foi concebido para multiplexar streams em uma única conexão. A especificação RFC 9113 define o comportamento de frames e streams, incluindo o RST_STREAM, usado para terminar um stream. A especificação é anterior à divulgação pública da CVE-2023-44487 e descreve o comportamento normativo; ela não é, por si só, uma análise retrospectiva do ataque nem uma solução pós-divulgação. A RFC 9113 define o comportamento de streams e frames do HTTP/2, incluindo o RST_STREAM.

Essa distinção importa. Um protocolo pode permitir que um cliente inicie e cancele streams sem que isso constitua, em abstrato, uma vulnerabilidade. O risco aparece na implementação concreta: criar um stream pode iniciar parsing, alocação, roteamento, autenticação, acesso a serviços ou outras tarefas antes que o cancelamento seja processado. Se o custo do cancelamento for baixo para o cliente e o trabalho desencadeado for alto para o servidor, a operação legítima se torna uma alavanca de exaustão de recursos.

A CVE-2023-44487 identifica justamente uma condição de negação de serviço que afeta implementações HTTP/2 por meio de resets rápidos e repetidos. Os registros do NVD, do programa CVE e do CERT/CC descrevem o problema como transversal a múltiplas implementações, e não como um defeito restrito a um único produto. O registro do NVD descreve a condição de negação de serviço e suas referências de produtos afetados. O programa CVE identifica a CVE-2023-44487 como o problema Rapid Reset. O CERT/CC descreve a abertura e o reset rápidos de streams e as medidas de mitigação.

A assimetria entre pedido e trabalho produziu a exposição

Os relatos técnicos publicados por Google, Cloudflare e Akamai convergem em um mecanismo: o atacante cria um stream e o cancela imediatamente, repetindo a sequência em alta velocidade. O servidor pode ter de aceitar, interpretar e iniciar o processamento do pedido antes de absorver o reset. O atacante mantém relativamente poucos streams ativos, mas força uma quantidade muito maior de trabalho de gerenciamento e processamento no servidor.

Google descreveu o Rapid Reset no contexto de atividade distribuída de negação de serviço observada em 2023. A publicação de segurança do Google registra a exploração observada em 2023. A análise técnica da Cloudflare descreve a sequência RST_STREAM e seus sinais operacionais. Cloudflare explicou a sequência de pedidos HTTP/2 seguida por frames RST_STREAM e relacionou os sinais de detecção a padrões anormais de criação e cancelamento. Akamai tratou o problema como uma técnica de negação de serviço no nível do protocolo e descreveu controles na borda para reconhecer o comportamento antes que ele alcançasse os sistemas de origem. Esses relatos são evidência técnica e operacional relevante, mas suas medições pertencem às respectivas redes e não devem ser generalizadas para toda a Internet. A análise do Google explica a criação e o cancelamento repetidos de streams e relata observações de ataques em larga escala. A análise da Cloudflare descreve a sequência RST_STREAM e seus sinais operacionais. Akamai descreve a técnica, a detecção na borda e controles antes da origem.

O ponto de responsabilidade não fica, portanto, em uma única camada. A especificação define uma superfície de comportamento. A implementação decide quanto trabalho realiza antes de reconhecer o cancelamento. O fornecedor escolhe como corrigir o produto, em qual ramo liberar a correção e se fará backport. A distribuição pode incorporar o patch sem alterar a versão principal aparente. O operador precisa instalar a atualização ou configurar um controle, verificar se o componente correto está em execução e observar se o padrão de ataque continua produzindo impacto.

A divulgação coordenada conectou descoberta e resposta

O caso também mostra como a detecção precisa atravessar fronteiras institucionais. A divulgação pública de 10 de outubro de 2023 veio acompanhada de explicações técnicas, identificador CVE, orientação de fornecedores e recomendações operacionais. O CERT/CC registra a coordenação com fornecedores afetados e recomenda atualizações dos fabricantes, além de controles específicos para limitar streams concorrentes, taxas de pedidos ou comportamento de resets quando a implementação oferece essas opções.

Um limite genérico de configuração não deve ser tratado como equivalente a um patch do fornecedor: a eficácia depende do produto, da versão e do ponto em que o controle é aplicado.

Os materiais do grupo de trabalho HTTP também registram discussão posterior sobre o Rapid Reset e possíveis respostas no texto do protocolo. O issue tracker do HTTP Working Group ajuda a reconstruir a revisão, as propostas concorrentes e a diferença entre modificar a especificação e recomendar salvaguardas de implementação. O rascunho HTTP/2bis mostra trabalho de revisão posterior à RFC 9113. Mas um Internet-Draft continua sendo trabalho em andamento, e comentários de issue não têm o mesmo status de uma RFC final. Tampouco a existência de uma mudança normativa demonstra que os sistemas implantados a adotaram. O rascunho HTTP/2bis documenta revisão posterior do texto do HTTP/2. O issue 846 registra a discussão sobre Rapid Reset e respostas possíveis no grupo de trabalho HTTP.

Essa é a primeira fronteira de accountability: quem controla a detecção e quem pode alterar a especificação. A IETF pode registrar o comportamento, reunir o grupo técnico e produzir texto normativo ou orientação. Ela não controla cada biblioteca, proxy, balanceador, distribuição Linux, appliance ou serviço que implementa HTTP/2. A legitimidade da resposta depende de deixar explícita essa separação, em vez de apresentar a publicação de uma revisão como prova de encerramento.

A correção virou uma cadeia de versões e pacotes

Os avisos de implementação tornam visível a segunda fronteira. A documentação de versão do Envoy identifica correções e mudanças de configuração relacionadas à mitigação em linhas de lançamento específicas. A orientação da NGINX distingue versões corrigidas de medidas de configuração ou implantação. O acompanhamento da Red Hat mostra por que o estado precisa ser verificado no nível do produto e do pacote: uma distribuição pode aplicar um backport sem alterar a versão principal do software upstream. A documentação do Envoy mostra correções e controles associados em uma linha de lançamento específica. A orientação da NGINX separa versões corrigidas de medidas de mitigação. A Red Hat acompanha o CVE por produto e pacote, inclusive com possíveis backports.

Isso impede uma conclusão simplista baseada apenas no nome do produto. Para saber se uma instância está protegida, é necessário identificar a implementação HTTP/2 efetivamente usada, a versão ou pacote implantado, o canal de atualização, a presença de backport e os controles ativos. Um release note do Envoy não prova o estado de um produto que incorpora Envoy de outra forma. Um aviso da NGINX não resolve o estado de uma distribuição que mantém outro ciclo de pacotes. Um status da Red Hat não pode ser extrapolado para bibliotecas empacotadas separadamente ou para outras distribuições.

A resposta correta, portanto, não é perguntar apenas “o fornecedor corrigiu?”. É perguntar: qual componente fazia o trabalho vulnerável, qual versão recebeu a correção, como o operador pode verificar sua presença e que controle permanece ativo enquanto a atualização não chega? Essas perguntas transformam uma declaração de remediação em uma trilha auditável.

Prioridade de exploração não mede exposição residual

A inclusão de uma vulnerabilidade no catálogo Known Exploited Vulnerabilities da CISA, se confirmada no snapshot citado, é evidência operacional de priorização por exploração conhecida. Para órgãos cobertos pelas regras aplicáveis, a entrada pode acionar prazos de remediação. Ela não mede a fração da Internet ainda vulnerável, não identifica todos os operadores expostos e não prova que a exploração cessou. O catálogo KEV da CISA é uma fonte de priorização para vulnerabilidades confirmadamente exploradas na natureza.

Essa limitação é central para a pergunta de encerramento. Um alerta público demonstra que a falha foi reconhecida. Um patch demonstra que existe uma via de correção. Uma configuração pode reduzir a superfície. Um registro KEV demonstra prioridade operacional. Nenhum desses fatos, sozinho, mede quantas instalações continuam vulneráveis ou se o serviço de uma organização específica está protegido.

As próprias medições de Google, Cloudflare e Akamai devem ser lidas com o mesmo cuidado. Elas fornecem sinais concretos de ataque, padrões de tráfego e experiência defensiva das redes que as observaram. Não constituem uma estimativa universal de prevalência. A ausência de um ataque observado em uma rede também não prova ausência de exposição em outra.

O que provaria um encerramento mais forte

A evidência de reparo durável precisa combinar camadas. Primeiro, deve haver uma definição precisa do comportamento que produzia o risco: criação e cancelamento rápidos de streams, trabalho de servidor desproporcional e esgotamento de recursos. Segundo, deve existir uma correção ou controle identificável no componente efetivamente usado. Terceiro, o operador deve demonstrar que a versão, o pacote ou a configuração corrigida está realmente implantada no caminho de tráfego relevante. Quarto, os sistemas de monitoramento devem ser capazes de detectar novamente o padrão e mostrar que o controle reduz o impacto.

Essa cadeia também precisa registrar incertezas. A documentação disponível não estabelece uma porcentagem universal de sistemas HTTP/2 que permaneceram vulneráveis depois da divulgação. Um fornecedor pode publicar uma correção sem saber quantos clientes a instalaram. Uma organização pode atualizar o proxy de borda e deixar um serviço interno ou um balanceador com outra implementação. Uma regra de limitação pode bloquear parte do ataque sem remover a assimetria de custo subjacente. Uma nova RFC pode esclarecer o comportamento sem alterar automaticamente o código já implantado.

A pergunta de accountability passa a ser verificável: quem é responsável por cada elo e que evidência pode produzir? O grupo de trabalho pode mostrar a discussão técnica. O fornecedor pode mostrar o release, o advisory e o intervalo de versões. A distribuição pode mostrar o pacote e o backport. O operador pode mostrar inventário, configuração, atualização e telemetria. Um investigador independente pode comparar declarações com comportamento observado. Se um elo não produz evidência, o estado correto é “não demonstrado”, não “corrigido”.

O limite institucional do caso IETF-W3C

O caso Rapid Reset não demonstra que uma única instituição falhou em cumprir uma obrigação simples. Ele demonstra um limite estrutural de sistemas técnicos distribuídos. A IETF e o ecossistema HTTP podem identificar o problema e revisar a superfície normativa; os fornecedores controlam código e releases; distribuidores controlam pacotes e backports; operadores controlam implantação e observabilidade; provedores de infraestrutura podem aplicar filtros e controles na borda.

Chamar isso de responsabilidade distribuída não deve significar diluir a responsabilidade. Ao contrário, exige atribuir cada decisão ao ator que controla a respectiva etapa e exigir uma prova correspondente. A instituição que publica um padrão não controla a implantação. O fornecedor que publica um patch não controla a instalação. O operador que instala uma atualização não controla as redes externas que continuam enviando tráfego. A resposta é legítima quando preserva essas fronteiras e torna os handoffs visíveis.

O aprendizado mais durável é simples: uma especificação corrigida é uma condição necessária em alguns casos, mas não é um certificado de segurança operacional. Para encerrar a exposição, a cadeia precisa passar de comportamento documentado a código corrigido, de código corrigido a pacote identificável, de pacote a implantação verificada e de implantação a redução observável do risco. O que não puder ser demonstrado deve permanecer como incerteza operacional.