NetCatTest

Anonimato & OPSEC

QUIC e HTTP/3 no Wireshark: CIDs, streams e TLS

Investigue uma sessão QUIC com HTTP/3 real de laboratório: duas requests, QPACK, rotação de CID e comparação de visibilidade com e sem key log.

Por Daniel Felipe 8 min leitura

QUIC e HTTP/3 no Wireshark mudam a investigação de transporte. A sessão utiliza UDP, mantém estado próprio, negocia criptografia e organiza streams. Procurar retransmissões TCP não responde à pergunta de como QUIC recuperou dados. Também é necessário distinguir Connection ID, número de pacote e identificador de stream.

No laboratório original da NetCatTest, a pilha aioquic 1.3.0 negociou HTTP/3, respondeu duas requests fictícias e rotacionou Connection IDs. Os datagramas criptográficos foram trocados entre máquinas de estado em memória e envolvidos em UDP/IP offline. O Wireshark 4.6.9 real confirmou os protocolos. Não houve acesso externo, captura pessoal nem migração real de rede.

O que o arquivo contém

Abra 30-quic-http3.pcap. Os endpoints fictícios são 192.0.2.30 e 198.51.100.30. Há 19 pacotes, handshake, controle HTTP/3, duas operações GET e encerramento. O domínio é aurora.test, validado pelo cliente com um certificado exclusivo do laboratório.

O pacote inclui um key log da experiência. Sem ele, a inspeção fica limitada aos elementos que o dissector consegue apresentar sem os segredos correspondentes. Com ele, o conjunto revela HEADERS e DATA HTTP/3. A comparação entre os dois modos faz parte da validação.

FramesObservação com segredos do laboratórioAlcance da conclusão
1 e 2Initial e HandshakeNegociação da sessão
3 a 5SETTINGS e controle de streamsInicialização HTTP/3
8 e 9Primeira request e responseOperação fictícia concluída
11 e 12Segunda request e responseOutro stream da mesma sessão
14 a 18Rotação e retirada de CIDsMudança de identificação, sem mudança de caminho
19Connection CloseEncerramento controlado

Primeira leitura: QUIC não se torna HTTP legível por usar UDP

quic
udp.port == 443
quic && tls.handshake.type == 1
http3

O filtro UDP/443 localiza o transporte do exercício. A árvore QUIC confirma o enquadramento. Uma porta comum não deve substituir essa confirmação: nem todo tráfego UDP nessa porta precisa ser QUIC válido.

Sem o key log, os testes do conjunto não encontraram frames HTTP/3 decodificados. Isso não significa que o tráfego de aplicação deixou de existir. Significa que a visibilidade mudou. O analista deve registrar a condição de decriptação usada ao apresentar screenshots e contagens.

Wireshark real mostrando a sessão QUIC de laboratório sem revelar os headers HTTP3 protegidos

A primeira leitura preserva a fronteira de visibilidade. A ausência de HTTP/3 decodificado não demonstra ausência de requests.

Initial e TLS: por que parte do início é reconhecível

A proteção dos pacotes Initial utiliza um procedimento que permite ao analisador interpretar parte da negociação a partir do contexto público correspondente. Isso não fornece os segredos de todo o conteúdo de aplicação. Reconhecer um ClientHello não equivale a ler as requests posteriores.

A RFC 9001 descreve a proteção de QUIC com TLS. Neste exercício, os segredos necessários para a aplicação foram gerados pela pilha, não deduzidos de uma captura pessoal. O certificado de laboratório valida a contraparte fictícia dentro do experimento.

Em relatórios, separe handshake interpretado, pacote protegido identificado e conteúdo HTTP reconstruído. A palavra “decriptado” sem delimitar quais camadas foram abertas pode exagerar o alcance da análise.

Segunda leitura: carregar somente os segredos do exercício

wireshark -n -r 30-quic-http3.pcap -o tls.keylog_file:30-quic-laboratorio.keys
tshark -n -r 30-quic-http3.pcap -o tls.keylog_file:30-quic-laboratorio.keys -Y http3 -T fields -e frame.number -e _ws.col.Info

O key log é exclusivo desta sessão sintética. Não contém chaves de navegador, credenciais do sistema ou dados de sites reais. Mantenha esse escopo ao reproduzir a análise. Em casos profissionais, segredos de sessão e PCAP real precisam de controles de acesso proporcionais ao conteúdo que podem revelar.

Com as chaves, o Wireshark identifica sete frames com HTTP/3. Duas requests GET aparecem nos frames 8 e 11. As responses dos frames 9 e 12 carregam JSON fictício indicando origem de laboratório e ausência de dados pessoais.

Wireshark real decodificando duas requests GET HTTP3 e respostas da sessão QUIC com chaves de laboratório

As operações HTTP/3 foram produzidas pela pilha real em memória. O transporte do PCAP é uma representação offline controlada.

Três identificadores que não devem ser misturados

O Connection ID ajuda a identificar contexto de conexão. O número de pacote pertence ao transporte QUIC. O identificador de stream organiza uma sequência lógica dentro da sessão. Cada um responde a uma pergunta diferente.

A mesma conexão pode utilizar vários CIDs ao longo da vida. Por outro lado, somar todos os valores distintos de CID como se fossem sessões independentes pode inflar um inventário. Confira as mensagens de controle e o vínculo entre os endpoints antes de definir a unidade de agrupamento.

No nosso conjunto, a pilha solicita uma troca de CID e continua sem alterar IP ou porta do caminho. A mudança é verdadeira no protocolo, mas o exercício não demonstra migração entre Wi-Fi e rede móvel. Essa limitação foi registrada no manifesto para impedir a extrapolação.

Rotação de CID não comprova migração

Os frames 14 a 18 incluem controle de novos e retirados identificadores. Uma análise que acompanha apenas a primeira string de CID pode perder parte da continuidade. Uma análise que atribui toda rotação a mudança de rede também cometerá erro.

Para sustentar uma conclusão de migração em um caso real, seria necessário observar alteração de endereço ou porta, validação de caminho e continuidade associada à sessão. Neste laboratório, os endpoints permanecem fixos. O teste mostra como a identificação pode mudar sem uma mudança física de rede.

A RFC 9000 é a referência do transporte QUIC. Para o leitor, a principal consequência é escolher uma chave de correlação que preserve estado e não dependa exclusivamente do par de endereços ou de um único CID.

Recuperação de dados: não procurar TCP Retransmission

QUIC utiliza seu próprio mecanismo de confirmação e recuperação. O arquivo não contém TCP, portanto os filtros de análise TCP não servem para classificar a recuperação dessa sessão. O fato de o transporte externo ser UDP também não implica ausência de entrega confiável nos streams.

Nosso conjunto não injeta perda de datagramas e não mede recuperação sob congestionamento. Para uma experiência desse tipo, seria necessário controlar perda e timers da pilha, preservar um log de envio e recebimento e comparar quais intervalos de stream foram novamente transmitidos. Não basta procurar dois pacotes UDP do mesmo tamanho.

O número de pacote pode mudar enquanto dados de stream são reapresentados. O relatório precisa distinguir o identificador do pacote e a posição do conteúdo transportado. A RFC 9002 oferece a base para estudar detecção de perda e controle de congestionamento.

HTTP/3 e QPACK: reconstrução depende de estado

As requests e responses usam cabeçalhos compactados e streams de controle. No PCAP validado, aparecem SETTINGS, unidades QPACK e os HEADERS das operações. Capturar apenas uma fatia tardia da sessão pode retirar informações necessárias para interpretar parte do conteúdo.

Se um arquivo real não apresentar um header esperado, confira primeiro decriptação, completude e disponibilidade dos streams de controle. Não atribua automaticamente a falha ao servidor. O laboratório completo fornece uma referência positiva para testar se a instalação do analisador consegue decodificar HTTP/3.

A RFC 9114 descreve HTTP/3, enquanto a RFC 9204 detalha QPACK. O nosso resultado observado é simples e reproduzível: duas operações HTTP/3 concluídas dentro de uma sessão QUIC com contexto disponível.

Comparar visibilidade sem confundir ausência e sigilo

Execute a mesma extração duas vezes, primeiro sem key log e depois com o arquivo exclusivo do laboratório. Preserve os dois resultados. A contagem de pacotes da captura continua 19; o que muda é a interpretação disponível para protocolos internos. Assim, a diferença de cobertura não deve ser apresentada como mudança de volume enviado.

Nos resultados com segredos, confira as duas requests e relacione as responses. Depois compare os CIDs antes e depois da rotação com o par IP/porta, que permaneceu estável. O conjunto permite testar se uma ferramenta conserva a continuidade da sessão e se evita declarar uma migração que não aconteceu.

Se o analisador não reconstruir HTTP/3, verifique a versão, a localização do key log e a correspondência com o PCAP publicado. Os segredos variam quando uma nova sessão é gerada. Um arquivo de chaves de outra execução não é um controle equivalente. O manifesto de hashes ajuda a manter a associação correta e impede comparar acidentalmente materiais de sessões diferentes.

Como documentar uma sessão sem exagerar a evidência

  1. Informe se há segredos de sessão e a autorização para utilizá-los.
  2. Confirme QUIC pelo enquadramento, não apenas pela porta UDP.
  3. Separe Connection ID, número de pacote e stream.
  4. Relacione CIDs novos e retirados antes de contar conexões.
  5. Diferencie rotação de CID e migração de caminho.
  6. Registre operações HTTP/3 observadas e lacunas de reconstrução.
  7. Meça perda ou impacto somente quando o experimento fornecer essa evidência.

O pacote de laboratórios da série inclui o PCAP, o key log sintético e as referências de validação. A API oficial do aioquic explica o modelo sem I/O usado na geração. O catálogo de campos QUIC do Wireshark permite conferir filtros e tipos na versão instalada.

Escrito por

Daniel Felipe é criador do NetCatTest e produz conteúdos sobre cibersegurança, privacidade digital, OSINT, laboratórios autorizados e ferramentas para estudo técnico responsável.

Compartilhar

Enviar este artigo