Anonimato & OPSEC
HTTP/2 no Wireshark: streams, RST_STREAM e janelas
Analise três streams na mesma conexão, esgotamento de janela HTTP/2, WINDOW_UPDATE, CANCEL e GOAWAY com frames reais de uma pilha de laboratório.
HTTP/2 no Wireshark pede uma investigação por stream, além da investigação por conexão TCP. Várias operações HTTP podem compartilhar o mesmo transporte. Um RST_STREAM pode cancelar apenas uma delas, enquanto outras já terminaram. Uma janela HTTP/2 esgotada também não equivale a TCP Zero Window.
No laboratório original da NetCatTest, três requests usam streams 1, 3 e 5. Uma resposta consome exatamente a janela anunciada, o cliente amplia essa janela, depois cancela o stream. A sessão termina com GOAWAY sem erro. Os frames foram produzidos pela pilha hyper-h2 4.4.1 em memória e lidos no Wireshark 4.6.9 real. Nenhuma requisição externa foi enviada.
Por que o laboratório usa h2c
O arquivo 23-http2.pcap possui 29 pacotes e usa TCP/8080 com HTTP/2 em claro por prior knowledge. Essa escolha permite ver os frames diretamente. Não é uma recomendação de configuração para uma API pública e não representa a negociação TLS de um navegador em produção.
Em uma captura HTTPS real, o acesso aos frames HTTP/2 depende da visibilidade do conteúdo TLS. O laboratório anterior explica essa condição. Aqui, a variável criptográfica foi retirada para estudar stream, controle de fluxo e enquadramento sem misturá-los com problemas de decriptação.
wireshark -n -r 23-http2.pcap -d tcp.port==8080,http2
tshark -n -r 23-http2.pcap -d tcp.port==8080,http2 -Y http2 -T fields -e frame.number -e http2.streamid -e http2.type -e _ws.col.InfoSe o protocolo não aparecer automaticamente, use Decode As para essa porta ou o argumento indicado. A porta 8080 não é prova de HTTP/2. A confirmação vem do preâmbulo e do enquadramento que o dissector consegue ler.
Conexão, frame e stream são três unidades diferentes
Uma conexão TCP transporta bytes. Dentro dela, HTTP/2 possui frames de controle e de conteúdo. Os streams organizam as operações. Um único pacote TCP pode carregar vários frames HTTP/2 e servir a mais de um stream.
O frame de captura 14 demonstra isso: contém HEADERS para streams 1, 3 e 5. O frame 16 agrega respostas e DATA. Portanto, contar pacotes que passaram por http2 não fornece diretamente o número de requests. Para medir operações, extraia os identificadores de stream e os headers correspondentes.
| Referência do PCAP | Conteúdo | Conclusão do exercício |
|---|---|---|
| 4 | Preâmbulo e SETTINGS | Inicialização do enquadramento |
| 10 | INITIAL_WINDOW_SIZE | Cliente anuncia 1.024 bytes |
| 14 | HEADERS dos streams 1, 3 e 5 | Três operações no mesmo TCP |
| 18 | WINDOW_UPDATE do stream 5 | Ampliação da janela da aplicação |
| 22 | RST_STREAM | Cancelamento do stream 5 |
| 24 | GOAWAY | Encerramento com código zero |
HEADERS e HPACK: a operação não está em uma linha de texto
As requests apresentam método, scheme, authority e path. O dissector reconstrói esses campos a partir do enquadramento e da codificação. Procurar a sequência textual de uma request HTTP/1.1 no payload bruto não é um método confiável para esse protocolo.
Selecione o frame 14, expanda os diferentes HEADERS e confira o stream correspondente. Os caminhos são /api/perfil, /api/pedidos e /relatorio. Nomes e dados são fictícios. A autoridade é aurora.test.
O frame 14 contém três operações. O índice do frame de captura e o identificador do stream HTTP/2 têm significados diferentes.
A RFC 9113 é a referência principal do HTTP/2. A RFC 7541 documenta HPACK. Para este exercício, o resultado prático é preservar a associação entre header reconstruído e stream, em vez de procurar apenas texto bruto.
Controle de fluxo HTTP/2 sem TCP Zero Window
O cliente anuncia uma janela inicial de 1.024 bytes por stream. O servidor usa todo esse orçamento no stream 5. A máquina de estado do servidor registra janela disponível igual a zero, impedindo novos DATA desse stream até que o cliente conceda mais espaço.
Enquanto isso, a janela TCP permanece aberta. O transporte poderia carregar outros frames, mas a aplicação precisa respeitar o orçamento HTTP/2. A árvore TCP e a árvore HTTP/2 respondem a perguntas diferentes. Uma pausa em DATA não autoriza concluir que o buffer TCP do receptor ficou cheio.
http2.type == 4
http2.type == 8
http2.streamid == 5
tcp.analysis.zero_windowNo arquivo validado, o filtro TCP Zero Window não retorna pacotes. O WINDOW_UPDATE do frame 18 amplia a janela do stream 5 em 2.048 bytes. O servidor envia uma continuação curta antes do cancelamento posterior. Essa sequência demonstra uma retomada controlada, não uma falha de conectividade.
RST_STREAM: uma operação foi cancelada
O cliente envia RST_STREAM para o stream 5 com código 8, CANCEL. Os streams 1 e 3 já receberam respostas completas. O evento não é um segmento TCP RST e não encerra automaticamente todas as operações na conexão.
Use o filtro por tipo e confira a árvore do frame 22. Em um relatório, registre stream, direção, código e estado da operação. Uma frase como “a conexão foi resetada” perderia a granularidade do evento e seria incorreta para esse controle.
RST_STREAM afeta o stream indicado. GOAWAY aparece depois com código zero no controle de encerramento.
GOAWAY: o último stream importa
O servidor termina a sessão HTTP/2 com GOAWAY de código zero e último stream 5. Esse dado informa o contexto de encerramento da aplicação. Não significa que todas as requests futuras foram executadas nem permite inferir resultado de uma operação que não está na captura.
Ao analisar uma interrupção real, compare streams iniciados, respostas concluídas e a informação de último stream. Antes de reproduzir uma operação, confirme se ela já foi processada. Reenvio automático de métodos que alteram estado pode duplicar efeitos quando o resultado ficou desconhecido.
Onde uma hipótese de ataque ganharia evidência
Uma sequência muito intensa de criação e cancelamento de streams pode justificar investigação de consumo de recursos. Porém, um CANCEL isolado também pode ocorrer por ação do usuário, timeout de aplicação ou mudança de navegação. O nosso conjunto possui um cancelamento intencional, sem volume suficiente para demonstrar negação de serviço.
Para avaliar um incidente, relacione a taxa de streams, simultaneidade, proporção de cancelamentos e trabalho executado no backend. Logs do servidor e métricas de fila mostram o efeito que o PCAP sozinho não mede. Preserve a distinção entre padrão compatível com abuso e impacto comprovado.
A captura deste laboratório não é uma reprodução de exploit e não prova vulnerabilidade de uma biblioteca. Seu objetivo é construir vocabulário e evidência para que cancelamentos normais não sejam confundidos com ataques, e para que um padrão anormal seja descrito com precisão quando houver contexto.
Extração sem perder múltiplas ocorrências
tshark -n -r 23-http2.pcap -d tcp.port==8080,http2 -Y http2 -T fields -E occurrence=a -E aggregator=, -e frame.number -e http2.streamid -e http2.type -e http2.headers.path -e http2.headers.statusComo um pacote pode incluir frames de streams diferentes, preserve todas as ocorrências. Uma tabela achatada que mantém apenas o primeiro stream pode ocultar operações. Para uma análise mais rica, use exportação estruturada e vincule cada frame HTTP/2 à sua própria unidade de stream.
A referência de campos HTTP/2 do Wireshark ajuda a conferir nomes e versões. A leitura do arquivo local também permite validar cada filtro antes de incluí-lo em uma regra operacional.
Um teste de completude para a sua ferramenta
Crie uma tabela com uma linha por operação, em vez de uma linha por pacote: stream 1, stream 3 e stream 5. A primeira coluna identifica o método e caminho; a segunda indica resposta; a terceira registra término normal ou cancelamento. Compare a tabela com os frames 14, 16 e 22. Se apenas a primeira request aparecer, a exportação provavelmente perdeu ocorrências.
Depois, faça uma segunda tabela exclusivamente para eventos de conexão, incluindo SETTINGS e GOAWAY. O CANCEL do stream 5 não deve transformar as outras duas operações em falhas. Essa separação também ajuda quando um coletor produz um alerta único para todo o TCP e apaga os detalhes internos.
O controle oferece critérios verificáveis: três operações iniciadas, duas respostas curtas concluídas, uma transferência maior cancelada e encerramento sem erro de conexão HTTP/2. Ele não testa carga, limites de memória do servidor ou resistência a abuso. Para medir esses efeitos seria necessário instrumentar um serviço autorizado e comparar recursos consumidos, mantendo o orçamento do experimento explícito.
Roteiro de investigação por stream
- Confirme o enquadramento HTTP/2 e a visibilidade do payload.
- Identifique o TCP que transporta a sessão.
- Liste cada stream, método, path e resposta.
- Separe controle de fluxo TCP e HTTP/2.
- Documente RST_STREAM por direção e código.
- Compare GOAWAY com operações concluídas e pendentes.
- Use telemetria do servidor para provar consumo ou impacto.
O pacote de laboratórios contém a captura, os filtros validados e o gerador. O diferencial da análise é manter as três unidades separadas: conexão transporta bytes, frames organizam o protocolo e streams representam operações independentes.
