Tsunami de CDN: Quando a eficiência do HTTP/3 se torna um amplificador de DDoS

O HTTP/3 foi criado para tornar a web mais rápida e resiliente. Ao substituir o TCP pelo QUIC, ele reduz a sobrecarga no estabelecimento de conexões, lida com a perda de pacotes de forma mais eficiente em fluxos simultâneos e é particularmente adequado para ambientes móveis e redes menos estáveis. Seu mecanismo de compressão de cabeçalho QPACK reduz ainda mais o volume de dados que precisam trafegar pela rede.

‍

Essas melhorias são significativas e o HTTP/3 está se tornando rapidamente o padrão. As medições do HTTP Archive de junho de 2026 mostram suporte ao HTTP/3 em 40,7% das solicitações de desktop e 42,2% das solicitações móveis, enquanto o W3Techs relata o uso de HTTP/3 em 40,3% dos sites em agosto de 2026. No entanto, a transição da Internet para o HTTP/3 não é uniforme. Em muitas implementações, o HTTP/3 termina em uma CDN ou proxy reverso, enquanto a comunicação com a origem da aplicação continua via HTTP/1.1 ou HTTP/2.

‍

Um artigo publicado recentemente, "CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks", mostra por que essa distinção é importante. Os pesquisadores demonstram que a diferença de eficiência entre os dois lados de uma CDN pode se tornar, por si só, uma fonte de amplificação de ataques DDoS. A lição não é que o HTTP/3 seja inseguro; pelo contrário, sempre que um intermediário traduz protocolos com características de recursos muito diferentes, a fronteira de tradução deve, ela própria, fazer parte do modelo de segurança.

‍

HTTP/3 na borda não significa necessariamente HTTP/3 na origem

Quando um navegador estabelece uma conexão HTTP/3 com um site, é fácil imaginar que o HTTP/3 continue até o servidor web que hospeda a aplicação. Isso é certamente possível hoje, mas está longe de ser universal. Uma arquitetura comum de CDN encerra a conexão QUIC do cliente, processa a solicitação HTTP e cria uma conexão separada em direção à origem do cliente usando uma versão anterior do HTTP.

‍

‍

A Cloudflare fornece uma ilustração útil. Sua documentação atual sobre HTTP/3 afirma que o HTTP/3 é suportado entre os usuários e a borda da Cloudflare, enquanto a conectividade HTTP/3 da Cloudflare para a origem ainda não é suportada. Existem boas razões operacionais para esse modelo: as CDNs podem implantar novos protocolos em suas próprias redes de borda sem exigir que os clientes atualizem simultaneamente servidores web, pilhas de aplicações, firewalls e balanceadores de carga.

‍

O compromisso é a assimetria de protocolo. Uma solicitação otimizada para transmissão eficiente via HTTP/3 deve ser eventualmente reconstruída em uma representação diferente antes de poder ser encaminhada para uma origem HTTP/1.1. O CDN Tsunami demonstra que um invasor pode explorar deliberadamente essa diferença.

‍

Quando a compressão se torna amplificação de largura de banda

O primeiro ataque descrito pelos pesquisadores é a Amplificação de Largura de Banda HTTP/3, ou HBA. O HTTP/3 usa o QPACK para comprimir cabeçalhos HTTP. Em vez de transmitir repetidamente campos de cabeçalho idênticos ou longos na íntegra, o QPACK permite que sejam representados de forma mais eficiente, inclusive referenciando entradas em uma tabela de compressão. Em circunstâncias normais, isso é exatamente o que queremos: menos bytes são transmitidos enquanto a mesma semântica HTTP é preservada.

‍

A situação muda quando a CDN precisa encaminhar a solicitação para um servidor HTTP/1.1. O HTTP/1.1 não entende QPACK, portanto, a CDN deve descomprimir e reconstruir esses cabeçalhos antes de enviá-los para o destino. O volume de dados que chega do invasor pode, portanto, ser substancialmente menor do que o volume de dados que a CDN transmite, em última análise, para a origem.

‍

‍

Os pesquisadores mediram taxas de amplificação que variaram de algumas dezenas de vezes, usando a tabela estática do QPACK, a aproximadamente 350 vezes em experimentos envolvendo sua tabela dinâmica. Em seu ambiente de teste controlado, menos de 500 Kbps de tráfego de ataque foram suficientes para gerar tráfego downstream capaz de sobrecarregar uma conexão de origem de 100 Mbps. Em vez de fornecer toda a largura de banda do ataque, os invasores convencem uma CDN a gerar a maior parte dela em seu nome.

‍

A eficiência da conexão também pode ser amplificada

A largura de banda é apenas uma das formas de consumo de recursos. A segunda técnica do CDN Tsunami, a Amplificação de Conexão HTTP/3 (HCA), tem como alvo as conexões de backend. O QUIC foi projetado para multiplexar muitos fluxos HTTP/3 independentes de forma eficiente em uma única conexão. Isso evita a sobrecarga associada à criação repetida de conexões TCP e permite que fluxos não relacionados progridam independentemente quando pacotes são perdidos.

‍

O problema surge quando esses fluxos de frontend são mapeados de forma ineficiente para conexões HTTP/1.1 de backend. Um pequeno número de conexões QUIC contendo muitos fluxos pode levar uma CDN a estabelecer um número muito maior de conexões TCP com a origem. A pesquisa constatou que várias implementações testadas começavam a alocar conexões de backend após receberem cabeçalhos de solicitação HTTP/3, em vez de aguardar a chegada da solicitação completa, permitindo que um invasor iniciasse muitos fluxos e entregasse lentamente os dados restantes.

‍

‍

A amplificação, neste caso, não é medida em gigabits por segundo. Ela é medida em tabelas de conexão, sockets, workers, memória e, por fim, no número de usuários legítimos que a origem ainda consegue atender. Isso é importante porque ataques DDoS nunca foram um problema exclusivo de largura de banda; qualquer recurso suficientemente limitado pode se tornar o alvo.

‍

A CDN torna-se o amplificador

Ataques de amplificação tradicionais tendem a seguir um padrão conhecido: um invasor envia uma pequena solicitação a um intermediário, como um serviço DNS mal configurado, que então gera uma resposta muito maior direcionada à vítima. O CDN Tsunami apresenta um problema diferente. O intermediário não é um serviço obscuro ou exposto indevidamente; é uma CDN legítima que a vítima colocou intencionalmente à frente de sua aplicação.

‍

O tráfego resultante que chega à origem pode, portanto, parecer legítimo. Ele vem de uma infraestrutura de CDN confiável, utiliza HTTP válido e pode até mesmo se originar de faixas de IP que o firewall do cliente incluiu especificamente em uma lista de permissões. Em muitas implementações de CDN, permitir que apenas endereços da CDN acessem a origem é considerado uma boa prática de segurança. Isso significa que perguntas convencionais como "De onde veio esse tráfego?" tornam-se menos úteis. Uma pergunta mais importante é: "Quanto trabalho de downstream essa solicitação de frontend aparentemente pequena causou?"

‍

‍

A segurança precisa considerar ambos os lados do proxy

A proteção contra DDoS na camada de aplicação baseia-se tradicionalmente em sinais como taxas de solicitação, taxas de conexão, reputação da origem, comportamento de URL, características de sessão e desvios de linhas de base de tráfego estabelecidas. Todos continuam úteis, mas a tradução de protocolo introduz outra relação que vale a pena monitorar: a amplificação de recursos do frontend para o backend.

‍

Uma solicitação de 2 KB que chega a um proxy e gera uma solicitação de 100 KB para a origem não é necessariamente alarmante quando cada lado é examinado de forma independente. Uma taxa de expansão de 50 para 1, no entanto, merece atenção. O mesmo se aplica às conexões: uma conexão QUIC que transporta dezenas ou centenas de fluxos HTTP/3 pode ser perfeitamente normal, mas se esses fluxos resultarem em conexões de backend excessivas, a contagem de conexões do frontend por si só oferece uma visão incompleta do risco.

‍

Portanto, proxies modernos e plataformas de proteção de aplicações precisam de visibilidade sobre essas proporções. Os controles relevantes incluem tamanhos máximos de cabeçalho descompactado, limites de QPACK, controles de simultaneidade de fluxo HTTP/3, restrições na expansão de conexões de backend, validação de solicitação antes da alocação de recursos de backend dispendiosos, tempos limite apropriados de fluxo e conexão, e detecção de proporções anormais de conversão de protocolo. Isso é frequentemente descrito como mitigação de HTTP/3, mas o princípio mais amplo é a governança de recursos: quanto trabalho a jusante uma unidade de atividade a montante deve ter permissão para criar?

‍

O HTTP/3 não é a vulnerabilidade

É importante não interpretar mal a pesquisa como uma crítica ao HTTP/3 em si. O QPACK está fazendo o que a compressão deve fazer, o QUIC está fazendo o que a multiplexação deve fazer, e a capacidade do HTTP/3 de mover mais informações com menos sobrecarga de conexão e transporte é um recurso, não um defeito.

‍

A vulnerabilidade surge quando essas eficiências podem se traduzir em consumo desproporcional de recursos em outros pontos da cadeia de entrega. A resposta, portanto, não é parar de adotar protocolos mais novos. A melhor resposta é tratar a conversão de protocolo como uma fronteira de segurança por si só.

‍

A adoção do HTTP/3 está crescendo, mas a transição é desigual

O HTTP/3 está agora suficientemente difundido a ponto de seu suporte se tornar uma consideração cada vez mais importante para provedores de CDN, entrega de aplicações e WAAP. Ao mesmo tempo, os números publicados sobre a adoção do HTTP/3 não devem ser confundidos com a proporção de servidores de origem que terminam nativamente o HTTP/3. Uma quantidade significativa do tráfego HTTP/3 atual termina em infraestrutura voltada para a Internet operada por CDNs e proxies reversos, enquanto as aplicações por trás dessa borda continuam a ser executadas em uma mistura de servidores HTTP/1.1, HTTP/2 e, cada vez mais, servidores compatíveis com HTTP/3.

‍

É improvável que esse ambiente heterogêneo desapareça rapidamente. As empresas substituem a infraestrutura de backend muito mais lentamente do que os navegadores e as redes de borda de hiperescala adotam novas tecnologias de transporte. A tradução de protocolo, portanto, continuará sendo uma parte normal da arquitetura da Internet no futuro previsível. A questão para os provedores de segurança não é se a tradução deve existir, mas se suas implicações de recursos são devidamente compreendidas e restringidas.

‍

Uma abordagem ponderada para o HTTP/3

O serviço de Proteção de Aplicações da Nexusguard não termina atualmente conexões HTTP/3 do lado do cliente. Em vez disso, os clientes negociam uma versão HTTP suportada, incluindo HTTP/2. Consequentemente, o caminho específico de conversão de HTTP/3 para HTTP/1.1 explorado pelo CDN Tsunami não está presente em nossa arquitetura atual de Proteção de Aplicações.

‍

Isso não deve ser interpretado como um argumento contra o HTTP/3. As vantagens de desempenho do QUIC e do HTTP/3 são claras, e o suporte ao HTTP/3 é uma área que continuamos a avaliar. No entanto, implementá-lo de forma segura exige mais do que apenas ativar o QUIC no frontend e traduzir solicitações para um protocolo de backend existente. A pesquisa CDN Tsunami reforça a necessidade de considerar a expansão de cabeçalhos descompactados, a simultaneidade de fluxos, a alocação de conexões de backend, a distribuição (fan-out) de frontend para backend e as taxas de amplificação de recursos como parte do próprio design.

‍

Existe também uma distinção importante entre proteger o tráfego QUIC e fornecer proteção de aplicação HTTP/3. Sistemas de DDoS na camada de rede podem detectar e mitigar muitos ataques volumétricos e de nível de transporte envolvendo UDP e QUIC sem encerrar a sessão HTTP/3. Compreender as solicitações HTTP, o comportamento do QPACK e a semântica de fluxo da camada de aplicação, no entanto, requer um nível mais profundo de conhecimento sobre HTTP/3. À medida que a adoção cresce, ambas as capacidades serão cada vez mais importantes.

‍

A maior lição da CDN Tsunami

A infraestrutura da Internet sempre evoluiu tornando-se mais eficiente. A compactação reduz a largura de banda, a multiplexação reduz a sobrecarga de conexão, as conexões persistentes reduzem os handshakes repetidos e o cache reduz a carga de trabalho da origem. Cada geração permite que mais trabalho útil seja realizado com menos recursos. Os atacantes observam essas mesmas eficiências na direção oposta: eles buscam situações em que uma pequena quantidade de seu próprio esforço possa fazer com que a infraestrutura de outra pessoa realize uma quantidade desproporcional de trabalho.

‍

A CDN Tsunami é um exemplo especialmente interessante porque nenhuma das tecnologias individuais precisa estar fundamentalmente quebrada. O HTTP/3 pode funcionar corretamente, o QPACK pode funcionar corretamente, o HTTP/1.1 pode funcionar corretamente e a CDN pode traduzir com sucesso entre eles. No entanto, a relação entre esses componentes que funcionam corretamente ainda pode criar uma oportunidade de amplificação.

‍

Essa é talvez a lição mais ampla para a defesa contra DDoS. Proteger a infraestrutura moderna exige cada vez mais não apenas procurar pacotes maliciosos ou solicitações excessivas, mas também assimetrias na forma como o trabalho se move através de um sistema. Sempre que um intermediário pode ser levado a fazer substancialmente mais trabalho do que a parte que o solicita, os atacantes têm uma vantagem potencial. À medida que os protocolos se tornam mais eficientes e a infraestrutura se torna mais interconectada, entender esses limites ocultos de amplificação pode ser tão importante quanto medir o próprio tráfego.

‍

Fontes

‍Artigo de pesquisa CDN Tsunami — arXiv, 29 de julho de 2026

‍RFC 9114 — HTTP/3

‍Documentação do HTTP/3 da Cloudflare — suporte de usuário para edge e limitação de origem

‍HTTP Archive — Estado da Web, suporte a HTTP/3

‍W3Techs — Estatísticas de uso do HTTP/3, agosto de 2026