Anonimato & OPSEC
TLS 1.3 no Wireshark: handshake e decriptação autorizada
Compare uma sessão TLS 1.3 antes e depois de carregar chaves exclusivas do laboratório. Handshake real, HTTPS fictício e prints do Wireshark.
TLS 1.3 no Wireshark permite investigar duas coisas distintas: o comportamento da sessão e, quando há material autorizado, o conteúdo protegido. Ver Application Data na lista não significa que o analista consegue ler a request. Também não significa que o tráfego foi perdido. Significa que parte da informação está protegida e que o alcance da observação precisa ser declarado.
Este laboratório contém um handshake TLS 1.3 verdadeiro, uma request HTTPS e uma response JSON. Os registros foram produzidos por OpenSSL através de MemoryBIO, com certificado exclusivo de aurora.test, e envolvidos em TCP/IP offline. O Wireshark 4.6.9 real foi usado para conferir a sessão. Nenhum socket externo foi aberto e nenhum certificado ou segredo pessoal foi utilizado.
O que foi produzido e o que não foi capturado
O arquivo 22-tls13.pcap tem 19 pacotes. Seus cabeçalhos Ethernet, IPv4 e TCP foram construídos para representar uma conversa completa entre 192.0.2.10 e 198.51.100.20. Os bytes TLS são reais: duas máquinas de estado criptográficas negociaram a sessão, validaram o certificado do laboratório e trocaram o conteúdo da aplicação em memória.
A temporização TCP é controlada. Portanto, a captura serve para estudar enquadramento, handshake e decriptação autorizada, mas não para medir latência de internet ou desempenho de um servidor de produção. Essa distinção evita apresentar um teste de protocolo como uma medição de rede física.
| Referência | Frame | Uso no exercício |
|---|---|---|
| ClientHello | 4 | Versões, SNI e propostas da sessão |
| Request HTTPS | 12 | Conteúdo visível somente com segredos do laboratório |
| Response HTTPS | 14 | JSON fictício e política de cache |
| Handshake e encerramento TCP | Início e fim do arquivo | Contexto do transporte offline |
Primeira leitura: sem arquivo de chaves
Abra o PCAP sem configurar o key log. Filtre TLS. O ClientHello permite observar o início da negociação. Os registros posteriores aparecem protegidos. A análise precisa preservar essa limitação: não é possível afirmar qual perfil HTTP foi solicitado apenas porque uma sessão TLS existiu.
tls
tls.handshake.type == 1
tls.record.content_type == 23
tcp.port == 443Os testes deste conjunto verificaram que http não retorna request ou response quando o arquivo de chaves está ausente. Esse controle é importante: se o conteúdo HTTP aparecesse sem os segredos, seria necessário verificar se o arquivo carregou chaves incorporadas, uma configuração anterior ou tráfego em claro.
Sem o key log exclusivo do exercício, o payload HTTP permanece protegido. O print não representa interceptação de uma sessão de terceiros.
ClientHello: proposta e resultado são dados diferentes
Selecione o frame 4. Expanda TLS e as extensões do ClientHello. O nome de servidor é aurora.test; a proposta de aplicação contém HTTP/1.1. Confira o que o cliente ofereceu antes de escrever o que foi negociado.
Uma lista de algoritmos propostos não comprova uso de todos eles. O resultado precisa ser confrontado com a resposta do servidor e com o estado final da sessão. No manifesto do laboratório, a pilha registra versão, cipher e ALPN efetivamente escolhidos. Isso fornece um segundo ponto de verificação para a leitura do PCAP.
A RFC 8446 define TLS 1.3. Seu enquadramento inclui características de compatibilidade que podem aparecer com valores de versão anteriores em campos do registro. A conclusão sobre TLS 1.3 deve considerar a negociação, não apenas um número isolado no cabeçalho.
Key log autorizado: escopo limitado à sessão do laboratório
O pacote inclui 22-tls13-laboratorio.keys. Ele contém exclusivamente segredos produzidos pelas sessões fictícias deste exercício. Foi mantido separado do PCAP para permitir comparação entre leitura protegida e leitura autorizada. Não reutilize um key log de navegador pessoal para reproduzir o exemplo.
No Wireshark, configure o campo de arquivo de segredos TLS em um perfil de laboratório ou abra pelo comando com uma preferência temporária. Evite salvar caminhos pessoais no perfil que será compartilhado. O caminho do comando abaixo é relativo ao arquivo da experiência.
wireshark -n -r 22-tls13.pcap -o tls.keylog_file:22-tls13-laboratorio.keys
tshark -n -r 22-tls13.pcap -o tls.keylog_file:22-tls13-laboratorio.keys -Y http -T fields -e frame.number -e http.request.method -e http.request.uri -e http.response.codeA documentação TLS do Wireshark explica o uso do key log. Aqui, a disponibilidade do segredo é uma condição do experimento, não uma falha da criptografia. Quem possui material suficiente da sessão pode reconstruir o conteúdo correspondente.
Segunda leitura: request e response reconstruídas
Com o key log correto, o frame 12 contém GET /api/perfil-lab. A response do frame 14 retorna JSON com perfil fictício, ambiente de laboratório e indicação de ausência de segredo real. O cabeçalho Cache-Control: no-store faz parte do controle observado.
A request e a response aparecem somente após carregar os segredos correspondentes. Os dados da aplicação são fictícios.
O resultado demonstra o conteúdo enviado pela aplicação do laboratório. Não demonstra que um cliente de produção respeitou determinada política de cache nem que um intermediário deixou de armazenar dados. Um cabeçalho observado e o comportamento completo do ecossistema são níveis diferentes de evidência.
Chave privada do servidor não é sinônimo de segredo de sessão
Uma dúvida comum é tentar abrir qualquer TLS moderno apenas com a chave privada do certificado. No exercício, a decriptação foi validada com os segredos da sessão. O material que autentica o servidor e o material que protege os registros desempenham papéis distintos.
Ao documentar um procedimento, diga qual tipo de segredo foi fornecido, de onde veio e a quais sessões se aplica. Uma descrição genérica como “adicione a chave” não é suficiente para alguém reproduzir o resultado. No pacote publicado, não há chave privada do computador: o certificado foi gerado exclusivamente para a experiência e seu uso é conhecido.
Reassembly: registros TLS não coincidem com pacotes TCP
Um registro pode atravessar vários segmentos, e um segmento pode carregar mais de um registro. A árvore do Wireshark apresenta relações de reassembly quando necessário. A contagem de pacotes TCP não deve ser usada como contagem de operações HTTP ou mensagens do handshake.
Se faltar um intervalo de bytes, o protocolo superior pode deixar de ser decodificado. Antes de concluir que a decriptação falhou por algoritmo, confirme a completude do transporte, a presença do ClientHello e a correspondência entre o key log e aquela sessão.
Neste arquivo, a sequência TCP é completa e os checksums foram verificados. Isso reduz as variáveis do exercício: uma diferença entre os dois modos de leitura deve se relacionar principalmente à disponibilidade dos segredos, e não a uma perda introduzida pelo gerador.
O que continua investigável quando não há segredos
Mesmo sem o conteúdo, é possível organizar endpoints, duração, tamanhos, sequência do transporte e comportamento de encerramento. Algumas características do handshake podem permanecer visíveis, dependendo do protocolo e das extensões utilizadas. Declare exatamente quais campos foram observados em vez de presumir a visibilidade de todos os nomes ou certificados.
Uma sessão longa com pequenos registros periódicos pode merecer contexto adicional, mas não identifica sozinha malware ou vazamento. Ferramentas de sincronização e aplicações legítimas também mantêm conexões duradouras. A correlação precisa incluir inventário, processo e finalidade autorizada.
Uma investigação que preserva o sigilo
Em trabalho profissional, segredos de sessão devem seguir controle de acesso e prazo de retenção. Publicar um PCAP junto com um key log real pode revelar dados que antes estavam protegidos. Para material didático, gere uma sessão independente, como fizemos aqui, e confira a ausência de informações pessoais antes de exportar.
A documentação de MemoryBIO no Python fundamenta o método usado para produzir registros TLS sem sockets. O benefício editorial é permitir exemplos criptograficamente válidos sem depender de tráfego da navegação do autor.
Checklist TLS para fechar a análise
- Registre versão do Wireshark, hash do arquivo e perfil utilizado.
- Separe valores oferecidos pelo cliente e valores negociados.
- Declare o que é visível sem segredos.
- Quando autorizado, confira a correspondência do key log com a sessão.
- Verifique reassembly antes de atribuir falha ao cipher.
- Relate request, response e política observada sem extrapolar comportamento não testado.
- Proteja PCAP e segredos como um conjunto quando houver conteúdo real.
O download da série inclui os dois modos de reprodução. A comparação mostra uma fronteira concreta de visibilidade: o analisador não remove a proteção da sessão sem material correspondente, mas consegue apresentar os protocolos internos quando esse material é fornecido de forma autorizada.
