Resumo

  • O TLS 1.3 protege juntos o conteúdo, um octeto de tipo interno e zeros finais de padding. O remetente escolhe o padding; o receptor o valida e remove antes de entregar o conteúdo. A representação adicional não ganha significado de aplicação.
  • Uma captura comprova tamanho do ciphertext, direção e tempo. Ela não separa conteúdo, tipo, padding e overhead de AEAD. Um registro maior, isoladamente, não comprova uma mensagem maior.
  • O padding pode agrupar impressões de tamanho e gerar tráfego de cobertura, mas não apaga tempo, quantidade, respostas, segmentação ou processamento. Conclusões exigem medidas do endpoint, política versionada, limites negociados e evidência de rejeição.

Um número correto recebeu poder demais

Dois registros pertenciam à mesma conexão. O maior apareceu próximo de uma operação sensível, e a diferença foi descrita como corpo da requisição e prova de uma ação humana.

O endpoint preservou o fato que faltava: um callback acrescentava zeros até o próximo limite de bloco. Nos períodos ociosos, outro componente também podia enviar Application Data com conteúdo vazio. Os bytes extras eram reais e consumiam banda, porém não eram todos dados do usuário.

O defeito não estava no sensor. Estava em permitir que uma evidência da camada de transporte decidisse a semântica após a descriptografia.

A fronteira dentro de TLSInnerPlaintext

TLSInnerPlaintext contém o conteúdo, depois um ContentType não zero e, por fim, uma sequência de zeros. A estrutura inteira é cifrada e autenticada. O tipo externo parece Application Data, portanto não revela o tipo interno ao observador.

Após a verificação AEAD, o receptor examina somente o plaintext devolvido, de trás para frente. Ignora zeros até encontrar o primeiro octeto não zero, que indica o tipo. O que vem antes é conteúdo. Se nenhum octeto não zero existir, deve encerrar com unexpected_message.

É nesse processamento que o limite adquire autoridade. A aplicação recebe o conteúdo sem padding. Zeros autenticados não viram comando, identidade, credencial ou permissão.

Cobertura possui gramática limitada

Application Data pode ter conteúdo interno de tamanho zero. O remetente consegue emitir um registro plausível quando não há bytes da aplicação, reduzindo a confiança na equivalência entre tráfego e atividade.

Handshake e Alert não podem usar a mesma forma. Um corpo vazio envolvido em padding continua inválido e deve ser rejeitado. O espaço ocupado não cria uma transição de protocolo.

Tráfego de cobertura tampouco garante privacidade completa. Resposta, atraso de processamento, rajada ou encerramento ainda podem distinguir trabalho real. O padding enfraquece um sinal, não todos.

Os zeros entram no limite

O máximo abrange conteúdo, tipo e padding. Quando record_size_limit é negociado, o valor recebido limita o TLSInnerPlaintext completo.

Uma política que pede 1.024 bytes não determina o resultado. O conteúdo já ocupa espaço; a implementação pode reduzir o acréscimo ou fragmentar de outra maneira. O código do OpenSSL calcula a folga e impede que o registro ultrapasse o máximo.

A mesma mensagem pode formar um registro, vários fragmentos ou uma classe menor que a solicitada. Sem limite, fragmentação e valor aplicado, o ciphertext final não reconstrói o caminho.

Mecanismo disponível não significa política ativa

A especificação atual do TLS 1.3 define codificação e validação, mas não escolhe bloco, distribuição ou frequência universal. A aplicação pode conhecer melhor os limites sensíveis de seus próprios dados; Handshake e Alert cifrados permanecem responsabilidade da camada TLS.

O padrão do OpenSSL é não adicionar padding. Há controles por bloco e callback antes da cifragem de cada registro escrito, com valores separados para Application Data e Handshake/Alert. Configurar callback pode impedir o uso de kernel TLS.

O GnuTLS oferece padding por envio e consulta de ocultação de tamanho. API instalada e registro IANA provam capacidade, não ativação, valor aplicado ou ganho de privacidade.

Tempo constante em uma camada não basta

A remoção dos zeros pode expor tempo relacionado ao tamanho. GNUTLS_SAFE_PADDING_CHECK reduz essa diferença com custo de desempenho.

Depois, a aplicação analisa conteúdo, aloca memória, consulta dados e responde. Essas ações continuam dependentes do conteúdo, mesmo que a biblioteca processe padding em tempo estável.

Por isso o TLS não promete defesa total contra análise de tráfego. Uma garantia maior requer cooperação do protocolo superior, volume adicional e, muitas vezes, atraso. “Padding habilitado” é estado de uma função, não resultado final de privacidade.

A composição escolhe a camada

EAP-TLS 1.3 recomenda padding de registro para reduzir vazamento do tamanho dos certificados. ECH arredonda o ClientHello interno e aponta mensagens cifradas posteriores cujos campos sensíveis podem exigir padding TLS. O objetivo deve vir antes do mecanismo.

HTTP/3 distingue frames de aplicação, frames reservados e padding no transporte. QUIC usa mensagens do handshake TLS, mas não carrega registros TLS comuns. Uma configuração de callback TLS não comprova padding de pacote QUIC.

As cipher suites de integridade sem cifragem mostram outra fronteira: o padding pode ser autenticado, porém não oculta o plaintext quando falta confidencialidade. Zeros, sozinhos, não criam sigilo.

O que o observador pode declarar

Uma captura passiva registra endpoints, direção, tempo, tamanho cifrado, pacotes e retransmissão. Não vê diretamente tipo interno, conteúdo, padding ou significado.

A formulação segura é: “o endpoint emitiu N octetos protegidos no instante T”. O log do processo pode completar: “recebeu C, executou política P versão V, aplicou Z, produziu tamanho interno I e ciphertext N sob limite L”.

Sem essa junção, uma distribuição sustenta hipótese, não atribuição de ação, objeto ou comando.

Evidência que sobrevive ao incidente

Registrar conexão, direção, sequência, versão TLS, proteção, tipo interno, conteúdo antes do padding, valor pedido e aplicado, tamanhos interno e cifrado, limite, fragmentação, versão da biblioteca, kernel TLS e revisão da política.

Medir banda, latência, CPU, classes de tamanho, correlação de respostas e proporção de cobertura. Separar Application Data de Handshake e Alert.

Testar plaintext só com zeros, Handshake e Alert vazios, pedidos excessivos e registros acima do limite. Guardar o alerta real. Depois da reversão, provar que callback e distribuição característica desapareceram.

O campo decisivo é invisível na captura: tamanho do conteúdo antes do padding. Sem ele, tamanho visível é evidência de rede, não autoridade de aplicação.

Fontes