Resumo

  • Finished comprova o transcript do handshake atual com o segredo negociado; dados de aplicação enviados antes da renegociação não entram automaticamente nessa prova.
  • A RFC 5746 carrega os verify_data anteriores para vincular a nova negociação. Principal, buffer, autorização, operação confirmada e resultado ainda pertencem à aplicação.

A nova identidade chegou depois dos primeiros bytes

Uma conexão segura já recebeu parte de uma requisição. Surge outro ClientHello, o servidor pede certificado do cliente, novas chaves entram em vigor e Finished é aceito. Para o TLS, a negociação terminou corretamente.

Na RFC 5246, verify_data combina o segredo mestre com o histórico das mensagens de handshake. A validação confirma que os extremos viram a mesma negociação. Não inclui, porém, os registros comuns de aplicação anteriores.

Antes da correção, faltava ainda um vínculo criptográfico entre a nova negociação e a conexão precedente. Um intermediário podia abrir a conexão, enviar um prefixo de aplicação e depois encaixar o handshake autenticado de outra parte. O servidor podia tratar prefixo e continuação como uma só mensagem. O segundo handshake era verdadeiro; a atribuição da conversa não era.

Estado de cifra não é estado de autorização

O TLS 1.2 mantém estados corrente e pendente. O handshake prepara algoritmos e segredos; ChangeCipherSpec ativa o pendente; Finished testa o resultado sob a nova proteção.

Essa sequência decide quais chaves protegem os próximos records. Não decide se uma requisição iniciada como anônima pode terminar como usuário autenticado. O socket continua igual, mas o fundamento de autoridade mudou dentro dele.

Buffers são o ponto cego. Se o terminador repassa ao serviço apenas o principal mais recente, a identidade nova pode recuar até bytes lidos antes dela. Cada camada registra sucesso e a composição produz uma permissão que nenhuma delas decidiu.

A costura de RFC 5746

Secure Renegotiation adiciona renegotiation_info e TLS_EMPTY_RENEGOTIATION_INFO_SCSV. No handshake inicial, os extremos anunciam suporte com um valor vazio. Na renegociação, a extensão contém os verify_data Finished anteriores do cliente e do servidor.

O novo handshake passa a provar conhecimento da saída do anterior. Um valor incompatível com a conexão mantida pelo extremo deve causar rejeição. Continuidade deixa de ser inferida do socket e passa a ser uma relação verificada entre duas negociações.

Mas o suporte não é execução. Uma biblioteca pode reconhecer a extensão enquanto a política bloqueia renegociação; o SCSV pode aparecer sem segundo handshake. O registro precisa distinguir capacidade, configuração carregada, sinal, resposta, ocorrência e comparação dos valores antigos.

O parser continua fora do perímetro TLS

A RFC 5746 não escolhe o destino de uma mensagem em andamento quando o principal muda. Descartar, concluir sob a identidade antiga ou reiniciar sob a nova são políticas possíveis, dependendo do protocolo.

O serviço deveria receber geração TLS e principal junto com cada mensagem. A transição exige uma decisão explícita sobre o buffer. Finished não autoriza retroativamente o que chegou antes.

Channel bindings da RFC 5929 permitem que protocolos superiores usem propriedades do canal. Ainda assim, produzir o binding, transportá-lo no protocolo, verificá-lo e associá-lo à operação são etapas separadas.

EMS e Secure Renegotiation não são o mesmo recibo

Extended Master Secret, RFC 7627, deriva o segredo mestre do hash do transcript e enfrenta problemas de session hash e triple handshake. Ele vincula segredo e handshake.

RFC 5746 vincula o handshake novo à conexão anterior por meio dos Finished anteriores. As duas defesas conectam objetos diferentes. Um indicador único de “TLS endurecido” perde exatamente a informação necessária para auditar a relação.

Registrar EMS, sinal e execução da renegociação segura, valor de ligação, caminho de certificado e principal produzido torna o sistema explicável sem expor segredos.

TLS 1.3 retirou a função; o estate não desapareceu

TLS 1.3 não oferece renegociação. A costura móvel some do protocolo. Isso não significa que todas as terminações tenham abandonado TLS 1.2. Um proxy pode falar 1.3 para fora e 1.2 para dentro; um fallback pode permanecer carregado sem aparecer em testes comuns.

A RFC 9851 congela novas funções ordinárias do TLS 1.2, mas não desliga listeners. Migração exige inventário, política efetiva, handshakes observados, dono de cada dependência e canários no caminho real.

Enquanto existir renegociação, uma trilha útil conserva handshake e Finished iniciais; intervalos de bytes; gatilho; sinal seguro; comparação anterior; nova identidade; ativação; novo Finished; principal; limite de mensagem; autorização; commit e resultado externo.

Essa trilha é análise da BTW, não formato obrigatório da RFC 5246. Ela impede que um forte recibo criptográfico responda por decisões que não viu.

Fontes