Resumo

  • O RFC 9850 define label client_random secret para sistemas em que TLS protege somente dados de teste; é Informational e diz que o mecanismo não deve ser usado em produção.
  • O master secret de TLS 1.2, os traffic secrets de TLS 1.3, exporters e ECH_SECRET transferem poderes diferentes; tratá-los como uma única “chave de depuração” esconde o raio de autoridade.
  • Sintaxe válida não prova permissão. Workload, ativação, consumidores, associação com captura, armazenamento, transporte, retenção, destruição e retorno a conexões sem log precisam de recibos próprios.

Quando um diagnóstico torna uma conexão TLS legível, surge um novo detentor de poder. A criptografia não falhou; um endpoint exportou estado privado suficiente para outro programa retirar a proteção dos records. O RFC 9850 torna essa exportação interoperável. A interoperabilidade não autoriza a operação.

O limite é explícito. Publicado em julho de 2026 como RFC Informational, o documento não integra o Internet Standards Track. O formato destina-se a sistemas nos quais TLS protege apenas dados de teste e o mecanismo não deve ser usado em produção. Para software compilado, recomenda-se a compilação condicional para impedir que binários implantados possam habilitar key logging. Não é uma recomendação de produção acompanhada de ressalvas.

Cada linha comum traz três valores separados por um espaço. label identifica o tipo de material. client_random é o Random de 32 bytes do ClientHello, codificado em 64 caracteres hexadecimais, para distinguir conexões. secret é hexadecimal e varia de tamanho conforme o label. Ferramentas devem aceitar diferentes fins de linha e letras hexadecimais em ambas as caixas. Podem até ignorar linhas inválidas para recuperar segredos utilizáveis de um arquivo corrompido.

Essa tolerância mostra o limite do parser. Ele pode afirmar que extraiu uma informação. Não pode afirmar que a coleta foi aprovada, que o arquivo está completo, que o prazo continua válido ou que o leitor pertence ao caso. Os três campos não contêm aprovador, ambiente, processo produtor, chamado, consumidor, expiração ou resultado de exclusão. Uma linha analisável prova formato, não mandato.

O client_random também não fecha a associação. O RFC informa que cipher suite e outros parâmetros não estão anotados; pode ser necessário manter o handshake correspondente. Packet capture e key log são artefatos separados que precisam compartilhar caso, workload e janela. Um diretório comum não prova que ambos nasceram da mesma autorização.

Em TLS 1.3, os labels dividem a capacidade por fase e direção: early traffic, handshake traffic de cliente e servidor, application traffic de ambos e exporter. Ler um trecho em uma direção não justifica coletar todas as fases. Minimizar significa limitar labels antes de limitar bytes.

No TLS 1.2, CLIENT_RANDOM identifica o master secret. Segundo o RFC 9850, seu possuidor pode ter muito mais acesso do que com segredos TLS 1.3 típicos: ler e alterar mensagens, retomar a sessão, personificar qualquer endpoint, inserir records que causem renegociação e forjar Finished. A implementação pode evitar tais riscos não registrando esse valor. Colocá-lo na mesma classe de um traffic secret direcional elimina a distinção central.

Exporters ampliam o raio para a aplicação. Protocolos podem usá-los em session binding, autenticação e outros segredos derivados. O RFC 9850 admite omitir esses valores onde possam ser abusados ou exigir autorização separada. A lista aprovada para inspeção de pacotes não é automaticamente a lista aprovada para material de identidade.

ECH protege outra superfície. ECH_SECRET corresponde ao shared secret KEM de HPKE, e ECH_CONFIG à configuração. A posse de ECH_SECRET permite revelar o Inner ClientHello, inclusive o SNI. Após ECH bem-sucedido, os labels TLS 1.3 usuais usam o Random interno; os labels ECH sempre usam o externo. Um índice genérico de “conexão” pode perder a diferença entre porta pública e nome oculto.

O poder não é apenas passivo. Como as chaves de record derivadas são simétricas, o detentor pode conseguir cifrar para uma conexão ativa e injetar ou modificar dados. Registrar material também remove a garantia de forward secrecy das conexões incluídas: uma pessoa que obtenha o log depois pode decifrar records guardados antes. É preciso demonstrar o conjunto exato afetado.

A autorização começa antes da primeira linha. Uma variável como SSLKEYLOGFILE põe a capacidade no contexto de lançamento do aplicativo. Um arquivo especial pode evitar persistência e ainda alimentar outro programa; remove uma mídia, não o consumidor. O recibo de ativação deve nomear workload de teste, build ou processo, labels permitidos, aprovador e horários de início e fim.

Depois da geração vem a custódia. Cada consumidor precisa de função e mecanismo de acesso; transferências precisam de origem, destino, integridade, proteção e expiração; armazenamento precisa de permissões e prazo; captura e segredo precisam do mesmo caso sem necessariamente terem o mesmo público. A exceção diagnóstica permanece estreita apenas quando cada novo detentor é visível.

Excluir o caminho original não fecha a cadeia. Ferramentas de análise, temporários, anexos, backups ou memória podem conter cópias. Não se afirma que sempre existam; enumeram-se os pontos possíveis e registra-se seu destino. Teardown exige logging desabilitado, produtor encerrado ou substituído, consumidores fora, cópias conhecidas destruídas, transferências vencidas e janela de captura fechada.

Conexões já registradas não recuperam a forward secrecy perdida. O retorno demonstrável começa em conexões posteriores com material novo e não exportado, uma superfície que deixou de produzir logs e uma verificação de que a aplicação funciona sem o canal diagnóstico. O registro da IANA estabiliza os nomes dos labels. Ele torna o poder legível; não demonstra o direito de exercê-lo nem o seu fim.

Fontes