Resumo

  • Cada KeyUpdate avança a chave de envio de um participante e a chave de recepção correspondente do outro. O sentido inverso só muda por meio de uma atualização própria.
  • Apagar gerações antigas pode resguardar o tráfego passado caso um segredo posterior seja exposto. Já o segredo atual permite derivar os futuros: rotação não é recuperação pós-comprometimento.

Uma conexão longa gasta um orçamento invisível

Depois do handshake, um canal TLS pode carregar milhares de transações sem chamar atenção para suas chaves. Mas os algoritmos AEAD têm limites probabilísticos de uso. O volume protegido por uma única chave afeta as margens de confidencialidade e integridade; conexão aberta não significa orçamento infinito.

Por isso, o RFC 8446 recomenda atualizar as chaves antes dos limites aplicáveis. O RFC 9325 reforça que aplicações com conexões duradouras precisam considerar sua política de renovação. Nenhum dos textos prescreve um intervalo universal: algoritmo, tráfego e risco continuam importando.

Versões anteriores do TLS ofereciam renegociação, uma operação ampla que podia reabrir parâmetros criptográficos e autenticação dentro de uma conexão em uso. O TLS 1.3 removeu essa função e reservou mecanismos menores para necessidades específicas. KeyUpdate não escolhe outra versão, não troca a suíte, não substitui certificados e não reinicia a sessão da aplicação. Ele cuida dos segredos de tráfego.

A mensagem antiga autoriza a geração nova

O emissor protege a própria mensagem KeyUpdate com as chaves antigas. Todos os records enviados depois dela usam as novas. O receptor autentica a instrução com seu estado atual e, só então, deriva a próxima chave de recepção.

Essa ordem coloca o limite de geração dentro da sequência protegida. Não há relógio externo nem instante presumido. Há também pouca tolerância para erro: mudar cedo demais torna a instrução ilegível; mudar tarde demais impede abrir o primeiro record novo.

O limite vale para um sentido. Os segredos de aplicação do cliente e do servidor são distintos. Quando um lado avança sua escrita, o outro avança a leitura correspondente; a escrita inversa permanece em sua geração.

Com update_not_requested, o processo termina assim. Com update_requested, o receptor deve enviar outro KeyUpdate, agora sem pedir nova resposta. Esse segundo ato atualiza o caminho inverso. Duas solicitações iniciadas independentemente podem se cruzar, e ainda assim cada lado deve responder. O protocolo proíbe acumular uma nova solicitação antes da resposta pendente, rejeita atualizações antes de Finished e exige defesa contra mensagens excessivas.

O apagamento protege para trás

Quando a transição está concluída, o segredo antigo pode ser eliminado. Se um atacante obtiver apenas uma geração posterior, a derivação unidirecional não lhe entrega automaticamente as anteriores. Capturas antigas podem continuar protegidas justamente porque o endpoint deixou de guardar o material necessário para abri-las.

Para a frente, a situação muda. Quem conhece o segredo atual consegue calcular seus sucessores. O KeyUpdate não acrescenta entropia independente e não repete a autenticação. Fazer a cadeia avançar depois do vazamento permite que o atacante avance junto.

Daí surgem duas respostas operacionais. Aproximar-se do limite de uso AEAD pede uma nova geração. Suspeitar que o segredo vigente foi exposto pede encerramento e um novo handshake com material fresco. Um painel que chama as duas ações de “rotação bem-sucedida” mascara a diferença entre manutenção e recuperação.

A distinção que o HTTP/2 precisava

Uma conexão HTTP/2 transporta muitos streams simultâneos. Alterar a identidade autenticada no meio dela cria ambiguidade sobre quais pedidos pertencem a qual identidade. O RFC 9113 proíbe, portanto, autenticação pós-handshake do TLS 1.3 no HTTP/2.

O mesmo documento permite KeyUpdate. Trocar a geração de proteção de records não muda diretamente a identidade nem a autorização de um request. Os streams continuam, enquanto um sentido criptográfico avança. A operação cabe no HTTP/2 porque sua autoridade é estreita.

QUIC escolheu outro mecanismo. O RFC 9001 proíbe mensagens TLS KeyUpdate em QUIC. Pacotes podem chegar fora de ordem, então o protocolo usa o bit Key Phase e regras de confirmação próprias. A finalidade é parecida; o procedimento ordenado do TLS não é universal.

Uma renovação sem novo começo

KeyUpdate não confirma confiança, não reautoriza o usuário, não apaga estado da aplicação e não prova que um incidente terminou. Seu trabalho é criar gerações direcionais de segredo dentro de uma conexão contínua.

Essa limitação é a contribuição histórica. O TLS 1.3 separou manutenção de chaves da antiga renegociação de amplo alcance. A próxima chave pode ser nova para fins de uso, mas continua ligada à origem que a derivou.

Fontes e limites

O texto se baseia nos RFC 8446, RFC 9001, RFC 9113 e RFC 9325. Eles não medem adoção atual, padrões de bibliotecas nem definem um prazo de atualização válido para todos os sistemas.