Resumo

  • O TLS 1.2 permitia um novo handshake dentro de uma conexão existente sem provar qual handshake anterior ele continuava.
  • O RFC 5746 salvou os verify_data do handshake anterior e exigiu sua verificação durante a renegociação.

Dois handshakes válidos, uma conversa falsa

O ataque começava quando o invasor estabelecia uma conexão TLS legítima com o servidor e enviava bytes de aplicação escolhidos por ele. Depois, fazia o handshake de uma vítima passar por essa conexão já protegida. Para a vítima, era um handshake inicial; para o servidor, podia parecer uma renegociação da conexão do invasor.

O invasor não conseguia ler o tráfego protegido da vítima. Isso, porém, não retirava o prefixo que já havia sido entregue. O servidor podia enxergar os bytes do invasor seguidos pelos dados autenticados da vítima e tratá-los como uma única interação. Em HTTPS, uma aplicação que não separasse as fases poderia associar a entrada escolhida pelo invasor a credenciais ou cookies enviados depois.

Não era uma falha de cifra nem uma falsificação de certificado. Cada handshake podia ter seus próprios Finished válidos. O que faltava era a prova de continuidade entre eles.

Transformando o Finished anterior em estado

O RFC 5746 adicionou o indicador secure_renegotiation e armazenou, por conexão, os verify_data do cliente e do servidor no handshake imediatamente anterior. Esses valores pertenciam à conexão ativa, não somente a uma entrada de cache de sessão que pudesse ser retomada.

A extensão renegotiation_info, tipo 0xff01, carregava essa história para a próxima negociação. No handshake inicial, renegotiated_connection ficava vazio. Na renegociação, o cliente enviava o client_verify_data salvo; o servidor o comparava com seu estado e retornava a concatenação dos valores do cliente e do servidor. O cliente verificava o resultado. Extensão obrigatória ausente ou valor divergente fazia o handshake ser abortado com falha fatal.

A interpretação é direta: completar um handshake já não bastava. Ele precisava ser o sucessor correto daquela conexão específica.

Um sinal de compatibilidade que não era uma cifra

Implementações antigas podiam falhar ao encontrar extensões desconhecidas. O RFC 5746 definiu então TLS_EMPTY_RENEGOTIATION_INFO_SCSV, 0x00,0xFF, na lista de conjuntos de cifras. Implementações antigas deveriam ignorar conjuntos desconhecidos, permitindo anunciar a capacidade sem depender de um analisador de extensões confiável.

O SCSV não era um conjunto negociável e não fornecia a vinculação das renegociações posteriores. Era um sinal do handshake inicial. Se o servidor não confirmasse a renegociação segura, o cliente não conseguiria maximizar ao mesmo tempo a interoperabilidade e a proteção contra o ataque de encaixe. O TLS tampouco distinguia sozinho um servidor que recusava toda renegociação de um servidor sem o reparo.

Do reparo à remoção

O TLS 1.3 escolheu outra fronteira: a renegociação é proibida. Um ClientHello recebido depois em uma conexão TLS 1.3 deve ser tratado como mensagem inesperada. Uma conexão estabelecida em versão anterior deve manter essa versão se receber um ClientHello de TLS 1.3 durante a renegociação; ela não pode ser atualizada dessa forma para TLS 1.3. KeyUpdate e autenticação pós-handshake são mecanismos distintos, não novas formas de renegociação.

Para TLS 1.2, o RFC 9325 exige que clientes e servidores implementem renegotiation_info, e que o cliente encerre a conexão se o servidor não reconhecer a extensão. O RFC 5746 também não resolveu todo problema de múltiplos handshakes; o RFC 9325 trata separadamente o extended master secret e o risco de triple handshake. Sua importância histórica é mais precisa: a continuidade temporal deixou de ser uma suposição da aplicação e passou a ser uma propriedade autenticada do protocolo.

Fontes