Resumo

  • A RFC 9850 define SSLKEYLOGFILE com três campos por segredo: rótulo, valor aleatório do ClientHello e segredo. Junto de tráfego capturado e contexto suficiente, o material pode remover a proteção TLS; sozinho, não traz horário, identidade do endpoint, autorização, procedência ou cadeia de custódia.
  • O poder vai além da leitura. Segredos registrados podem abrir tráfego antigo, permitir injeção em conexão ativa, afetar aplicações que dependem de exporters, derrotar forward secrecy e, no caso do segredo mestre do TLS 1.2, ampliar a capacidade de personificação.
  • O RFC restringe o mecanismo a sistemas em que TLS protege somente dados de teste e proíbe uso em produção. Decifrar com sucesso prova compatibilidade entre segredo e records, não quem se comunicou nem se a coleta era legítima.

Um resultado executável ainda precisa de procedência

Há uma diferença entre um log que afirma “sucesso” e um segredo que efetivamente abre records autenticados. O segundo resultado é mais forte porque pode ser repetido. Ainda assim, repetibilidade criptográfica não é cadeia de custódia.

Para afirmar que uma pessoa executou uma ação, a equipe precisa saber onde a captura começou, qual interface e filtro foram usados, qual relógio marcou os pacotes e o que se perdeu. Precisa identificar o processo que emitiu o segredo, o build que continha a função, o contexto que a ativou e a autoridade de quem pediu a coleta. Depois vêm hashes, armazenamento, acessos e transferências.

O key log participa dessa cadeia. Ele não substitui a cadeia. Seu resultado legítimo é estreito: determinados materiais e determinados records funcionaram juntos sob uma interpretação documentada do handshake.

Padronização coletiva de uma prática anterior

Publicada em julho de 2026 como RFC Informational, The SSLKEYLOGFILE Format for TLS tem Martin Thomson, Yaroslav Rosomakho e Hannes Tschofenig como autores. Os agradecimentos registram que o formato nasceu no projeto Network Security Services e mudou com o TLS; os autores documentam o uso existente e acrescentam suporte a Encrypted Client Hello.

O perfil oficial do IETF guardado em 1º de setembro descreve Thomson como engenheiro da Mozilla, lista 45 RFCs e mostra funções vigentes em grupos de trabalho, revisão e ligação com o W3C. O registro situa sua contribuição. Não lhe atribui invenção exclusiva, verificação de produtos, controle sobre deploys nem autoridade para aprovar uma interceptação.

A IANA mantém os rótulos SSLKEYLOGFILE. Isso permite que implementações e ferramentas falem a mesma língua. O próprio RFC alerta que a aprovação de um rótulo por especialista designado não representa endosso. Registrar uma palavra compartilhada não autoriza a operação que produz o segredo.

O alcance de label, client_random e secret

O label informa a classe do segredo. O client_random reproduz os 32 bytes Random do ClientHello e ajuda a encontrar uma conexão dentro de um arquivo com várias. O secret carrega o valor correspondente em hexadecimal.

Da definição surge uma inferência estrutural — e deve ser apresentada como inferência, não como frase do RFC. Não há campo obrigatório para timestamp, hostname, IP, porta, certificado, processo, usuário, decisão de autorização, histórico de acesso, referência da captura ou custódia. O ClientHello random correlaciona elementos; não identifica uma pessoa.

A especificação explicita outra ausência: os segredos não vêm anotados com cipher suite e outros parâmetros de conexão. Talvez seja preciso ter o handshake para usá-los. O arquivo, portanto, não é uma transcrição autossuficiente da sessão.

Também é possível copiar uma linha bem formada ou produzi-la fora da captura alegada. Isso não torna inútil o arquivo verdadeiro. Torna indispensáveis a aquisição controlada, os hashes, os relógios e a confirmação por outras fontes.

A mesma capacidade remove confidencialidade e integridade

A falta de identidade não reduz a gravidade do segredo. A RFC 9850 diz que acesso ao conteúdo pode romper confidencialidade e integridade de conexões ativas e de records cifrados guardados anteriormente.

As chaves derivadas são simétricas. Quem consegue remover a proteção pode, nas condições relevantes, também cifrar dados para uma conexão ativa. A possibilidade de injetar ou modificar conteúdo exige separar no relatório o tráfego observado do tráfego criado pela própria análise.

Exporter secrets alcançam mecanismos acima do record TLS. Aplicações podem usá-los para session binding, autenticação ou novos segredos. Um vazamento pode quebrar uma relação de confiança que não aparece como simples conteúdo do pacote.

Forward secrecy também deixa de proteger o passado quando o material de tráfego é gravado. Uma captura que parecia segura para retenção pode ser aberta anos depois ao encontrar o key log correto.

O rótulo muda o risco. No TLS 1.3, há materiais separados de handshake, aplicação, early data e exporter. No TLS 1.2, CLIENT_RANDOM contém o segredo mestre; a RFC inclui leitura, alteração, retomada, personificação dos dois endpoints, inserção de renegociação e falsificação de Finished entre as consequências. ECH_SECRET pode expor o Inner ClientHello e o SNI. “Arquivo presente” não é classificação suficiente.

A proibição de produção começa no build

A RFC não descreve key logging como observabilidade normal que possa ser compensada por ACL. O formato se destina a sistemas em que TLS protege apenas dados de teste e não deve ser usado em produção. Para software compilado, recomenda conditional compilation para que o binário implantado não possa habilitar a função.

Esse é um controle preventivo. Sem o hook, variável de ambiente, launcher comprometido e runbook improvisado não conseguem gerar o segredo. Em laboratório ainda são necessários acesso mínimo, vida curta e descarte comprovado. Em produção, permissões não substituem a remoção da capacidade.

O problema cresce quando “temporário” vira infraestrutura. O diretório permanece, um coletor passa a lê-lo, backups o preservam e outra plataforma guarda packet captures. Dois inventários antes separados tornam sessões antigas reabríveis.

Encontrar a capacidade em produção pede contenção: localizar build e contexto de execução, interromper emissão, proteger arquivos e capturas, delimitar conexões, verificar exporters e ECH, e preservar evidência sem espalhar segredos por chats e tickets.

O handshake não transfere sua autenticação para o arquivo

A RFC 9846 descreve o handshake do TLS 1.3 como negociação, autenticação segundo o mecanismo escolhido — a autenticação do cliente é opcional — e estabelecimento de material compartilhado. O protocolo de aplicação ainda decide qual identidade espera e como valida certificados.

SSLKEYLOGFILE exporta resultados do key schedule. Não refaz certificate validation, não informa o reference name, não afirma que o cliente foi autenticado e não associa um ser humano ao endpoint. Mesmo com o handshake capturado, identidade e política de validação precisam de recibos próprios.

Falhar ao decifrar também não prova fabricação. Conexão errada, handshake ausente, key update, direção, escolha de random em ECH ou contexto de protocolo integrado podem explicar o resultado.

A RFC 9325 trata autenticação, confidencialidade e integridade como objetivos separados. Um artefato capaz de neutralizar dois não recebe autoridade sobre o terceiro.

Capacidade técnica não vira autoridade documental

Em The Policy Mirror, Heng Lu separa o registro que descreve do poder que pretende criar realidade. Running-Code Primacy limita o artefato comum à função verificável exigida por sistemas em operação. On Reality Layers distingue efeito executável de afirmação simbólica.

O efeito executável aqui é enorme: segredo e capture correspondentes podem revelar ou alterar tráfego. O excesso simbólico é tratar a linha de três campos como prova da sessão, das pessoas e da legitimidade da coleta.

Thomson, Rosomakho e Tschofenig contribuíram para tornar a convenção interoperável e para explicitar sua fronteira. O número do RFC e o registro da IANA não autorizam produção. Autores respondem pelo texto; implementadores, pelo código; responsáveis de release, pelo binário; operadores, pela execução; investigadores, pela procedência e interpretação.

O recibo completo fica ao redor do key log

Antes de decifrar, registrar build, ativação, solicitante e autorização, processo e ativo, intervalo, permissões, hashes, armazenamento e cada transferência. Para o capture, registrar interface, direção, filtro, relógio, perda, handshake, tupla e hash.

Na análise, guardar label, ClientHello random, parâmetros recuperados, ferramenta e versão, records autenticados, falhas e qualquer ação ativa. Na conclusão, separar chave de endpoint de identidade humana, bytes decifrados de tela exibida, request capturado de resultado de negócio e teste autorizado de permissão geral de interceptação.

O key log continua valioso quando se recusa a responder ao que não contém. Ele vira um instrumento confiável, não uma história soberana.

Fontes