Resumo

  • A falha permitia que duas negociações TLS na mesma conexão fossem tratadas como um único contexto de aplicação sem uma ligação criptográfica entre elas.
  • RFC 5746 corrigiu essa fronteira; TLS 1.3 removeu a renegociação, mas somente testes, inventários, responsáveis por exceções e evidências de retirada demonstram o encerramento em ambientes reais.

O problema não era simplesmente a existência de uma segunda negociação. O TLS 1.2 permitia que uma nova negociação ocorresse sobre uma conexão já existente, mas o desenho anterior não afirmava criptograficamente que a nova negociação pertencia à anterior. O RFC 5246 descreveu a renegociação no TLS 1.2; o RFC 5746 documentou a vulnerabilidade e definiu a correção.

O caminho de exploração dependia dessa fronteira ausente. Primeiro, o atacante estabelecia uma conexão TLS com o servidor. Depois, enviava bytes de prefixo escolhidos para o protocolo de aplicação. Em seguida, a negociação da vítima era retransmitida ao servidor como renegociação na conexão já criada pelo atacante. O servidor podia autenticar a vítima na nova negociação enquanto mantinha os bytes anteriores do atacante no mesmo fluxo de aplicação. O efeito documentado era injeção de prefixo limitada, não descriptografia do tráfego protegido da vítima nem reescrita arbitrária de todos os bytes posteriores. A consequência prática dependia da forma como o protocolo de aplicação interpretava o fluxo. O catálogo de ataques conhecido do IETF descreveu esse mecanismo e seu caráter limitado.

RFC 5746 introduziu duas peças com funções diferentes. A extensão renegotiation_info transporta dados de verificação que vinculam a renegociação à negociação anterior. O sinal TLS_EMPTY_RENEGOTIATION_INFO_SCSV permite indicar suporte à renegociação segura durante a negociação inicial. O sinal demonstra suporte; os dados de verificação fornecem a ligação criptográfica. Essa distinção é importante: declarar compatibilidade não é o mesmo que provar que uma conexão insegura será rejeitada ou restringida. O RFC 5746 define esses mecanismos, enquanto a orientação operacional do RFC 7525 trata do uso seguro das versões anteriores.

A arquitetura posterior mudou a fronteira de outra maneira. O RFC 8446, que definiu o TLS 1.3, removeu a renegociação. Funções posteriores mais estreitas, como KeyUpdate e autenticação pós-negociação, não mantêm a renegociação geral como recurso. O RFC 9325 substituiu o RFC 7525 e preservou orientações para versões antigas, reconhecendo a remoção da renegociação no TLS 1.3.

Isso resolve o protocolo, não o inventário. Um padrão publicado define o comportamento esperado na camada de fio. Implementadores de bibliotecas e produtos precisam implementar a extensão, aplicar as verificações e oferecer políticas seguras. Operadores precisam testar endpoints públicos e internos, revisar appliances e camadas de terminação, registrar exceções e retirar caminhos legados. Donos de aplicações precisam verificar se bytes de prefixo controlados por um atacante podem alterar autorização ou interpretação de requisições. Nenhuma dessas responsabilidades pode ser substituída por uma declaração de que um produto “suporta” RFC 5746.

A evidência de encerramento deve acompanhar o caminho do serviço. Um frontend que negocia TLS 1.3 não prova o estado de um salto interno, de um appliance ou de uma biblioteca usada a jusante. A aceitação de renegociação insegura em qualquer endpoint TLS 1.2 ou anterior deve abrir uma correção. Cada exceção deve ter responsável, dependência afetada, controle compensatório e data de expiração. Testes de endpoint, inventário de versões e prova de retirada precisam ser mantidos como registros separados.

O conjunto de RFCs não estabelece quantos ataques ocorreram, a configuração atual de qualquer operador ou a implantação universal de RFC 5746. Também não prova que todo serviço tenha abandonado o comportamento legado. A conclusão sustentável é mais estreita: o IETF definiu a falha, vinculou a renegociação anterior por meio de RFC 5746 e depois eliminou a renegociação no TLS 1.3. A pergunta operacional que permanece é quais evidências demonstram que essa correção continua válida em todos os caminhos legados relevantes.