Resumo

  • No TLS 1.3 atual, definido pelo RFC 9846, KeyUpdate avança o segredo de tráfego de aplicação de uma única direção. A mensagem de transição ainda usa a chave antiga; os registros seguintes do emissor usam a nova geração.
  • update_requested normalmente exige uma resposta antes do próximo dado de aplicação, mas a exigência é delimitada. Pedidos simultâneos podem se cruzar, vários pedidos silenciosos podem ser consolidados e o limite da época de envio continua sob controle local.
  • Evidência confiável separa agendamento, emissão, aceitação e primeiro dado protegido pela nova geração. Nenhum desses marcos, isolado ou em conjunto, prova que a memória antiga foi apagada, que a identidade foi autenticada novamente ou que uma ação de negócio foi autorizada.

A dobradiça ainda usa a chave antiga

Considere um canal TLS que transporta telemetria por muitas horas. O servidor resolve avançar sua chave de envio e pede que o cliente também atualize a dele. A instrução cabe em uma KeyUpdate com request_update=1, mas o efeito não acontece como uma virada global.

Primeiro, o servidor cifra a própria KeyUpdate com a geração que está abandonando. Depois de emitir esse registro, passa a proteger todo novo tráfego servidor-cliente com o segredo seguinte. O cliente precisa autenticar a ponte antiga antes de avançar a cadeia de recepção correspondente. Se responder, sua KeyUpdate sai sob a chave antiga do sentido cliente-servidor; só então seus registros futuros adotam a geração seguinte.

Há, portanto, dois relógios e duas cadeias. Um painel que reduz a sessão a “versão da chave = 7” elimina justamente a assimetria que explica falhas, atrasos de I/O e pedidos cruzados.

A referência vigente é o RFC 9846

O RFC 9846 substituiu o RFC 8446 em 2026, preservando a interoperabilidade do TLS 1.3 e tornando explícitos limites que importam para conexões longevas. KeyUpdate continua sendo a mensagem de handshake tipo 24 e admite somente update_not_requested(0) e update_requested(1).

Recebê-la antes de Finished exige unexpected_message; um valor desconhecido exige illegal_parameter. A mensagem deve terminar na fronteira do registro anterior à troca. O receptor não pode aceitar dados com a chave seguinte antes de autenticar essa transição sob a chave antiga, porque remover a ponte abre espaço para truncamento.

O sucessor é derivado do segredo direcional corrente por HKDF-Expand-Label com o rótulo traffic upd. Novas chave e IV nascem dessa derivação. O emissor tem teto de época 2^48-1; o receptor não deve aplicar esse teto em nome do outro lado, pois uma especificação futura pode mudar a regra do emissor.

Um direito protocolar com fronteira

Quando o bit vale zero, o peer apenas comunica a própria mudança. Quando vale um, o destinatário normalmente deve enviar uma KeyUpdate sem novo pedido antes do próximo Application Data. Isso é uma obrigação real, não uma transferência de soberania sobre o processo local.

O padrão proíbe acumular um novo pedido enquanto outro permanece pendente. Vários pedidos recebidos durante o silêncio do peer podem ser atendidos por uma única atualização. Se ambos os lados enviarem pedidos ao mesmo tempo e as mensagens se cruzarem, cada um ainda responde, de modo que as duas direções podem avançar duas gerações.

Se a resposta ultrapassaria o teto local, o emissor não deve executá-la e deve ignorar o pedido. A conexão pode mais tarde atingir o limite de uso do AEAD e precisar terminar. Autenticar um pedido não cria direito ilimitado a CPU, memória, geração de segredos ou sobrevivência da sessão.

Continuidade não é apagamento

Quem não possui o segredo atual não consegue saltar para o seguinte apenas observando o fio. Essa continuidade é forte. Já a eliminação do segredo antigo ocorre dentro da implementação. O RFC orienta apagar o material anterior depois da derivação, mas um registro novo não inspeciona heap, enclave, tabela de offload, core dump ou cópia de segurança remota.

Uma organização só pode afirmar descarte a partir de evidência local de memória e ciclo de vida. A resposta do peer comprova compatibilidade com a nova cadeia, não higienização da antiga. Misturar as duas alegações transforma interoperabilidade em atestado falso.

KeyUpdate também não reautentica. Certificado, identidade do serviço, identidade do cliente e parâmetros negociados permanecem os mesmos. Chaves recentes podem proteger perfeitamente uma requisição de aplicação que nunca deveria ter sido autorizada.

As bibliotecas revelam tempos diferentes

No OpenSSL, SSL_key_update() agenda o trabalho após o handshake inicial. A atualização chega ao fio quando uma operação posterior de I/O, ou uma chamada que impulsione o handshake, a processa. O retorno da função não é evidência de emissão, e a aplicação precisa coordenar escritas pendentes.

O GnuTLS expõe a escolha direcional: sem o sinalizador do peer, atualiza o envio local; com GNUTLS_KU_PEER, também pede a renovação contrária. A operação pode seguir o comportamento não bloqueante dos registros, e a documentação separa explicitamente rekey de reautenticação.

O rustls oferece refresh_traffic_keys() e acompanha limites de confidencialidade no fluxo normal. Quando a proteção de registros é externalizada pela interface de kernel, passam para a aplicação a contagem aproximada, a renovação e a decisão de abortar. Deslocar a cifra não desloca a responsabilidade.

TLS, DTLS e QUIC exigem provas distintas

O QUIC usa TLS 1.3 no handshake, mas proíbe mensagens TLS KeyUpdate. A versão 1 gira a proteção de pacotes com Key Phase, confirmações e a derivação quic ku. Um contador de mensagens KeyUpdate mostraria zero mesmo durante uma renovação QUIC correta.

O DTLS 1.3 preserva KeyUpdate em um ambiente com perda e reordenação. Usa épocas, confirma atualizações e pode manter material de recepção antigo para datagramas atrasados. Uma resposta pode cruzar o pedido e não serve automaticamente como confirmação dele.

“Rekey TLS” é, portanto, uma categoria operacional ampla demais para auditoria. Stream TLS pede a ponte ordenada; DTLS, movimento de época e confirmação; QUIC, mudança de fase de pacote. O objetivo pode ser igual, mas o objeto probatório não é.

Um registro defensável sem segredos

O ledger deve guardar referência estável da conexão, papel, transporte, versão, direção e gerações anterior e posterior. Deve registrar o iniciador — política, limite da biblioteca, operador ou peer —, o valor do pedido, o estado pendente, a autenticação da ponte antiga, a fronteira de registro, a primeira aplicação bem-sucedida da nova chave, consolidações, cruzamentos e eventual alerta terminal.

Quatro marcos não podem virar um só: agendado, emitido, aceito e usado com sucesso. A comprovação de apagamento pertence a outro registro, controlado localmente, sem copiar bytes de chave para observabilidade. Captura de pacotes também não basta, porque TLS 1.3 cifra KeyUpdate; testes controlados podem correlacionar callbacks e contadores sem transportar segredo para produção.

Fontes