Resumo

  • A RFC 8446, de agosto de 2018, negocia a versão real do TLS 1.3 por supported_versions. Os campos legacy_version conservam 0x0303, número do TLS 1.2; examiná-los isoladamente não revela o protocolo em uso.
  • Se um servidor capaz de TLS 1.3 negocia TLS 1.2, deve encerrar ServerHello.random com 44 4F 57 4E 47 52 44 01. Se negocia TLS 1.1 ou anterior, o último byte passa a 00. Um cliente TLS 1.3 que encontra uma dessas marcas numa resposta de versão antiga deve abortar.
  • A RFC 7507, de 2015, tratou de outro caminho: uma tentativa repetida pelo cliente em versão inferior pode levar TLS_FALLBACK_SCSV, levando um servidor capaz de versão superior a responder inappropriate_fallback. A IANA registra a indicação e o alerta.

O número antigo na portaria

Quem lê apenas ServerHello.legacy_version numa negociação TLS 1.3 pode classificá-la como TLS 1.2. A RFC 8446 deixa 0x0303 nesse campo e transfere a decisão para supported_versions. O nome “legacy” explica a tarefa: conservar o formato reconhecível, não certificar qual protocolo os extremos executam. Um sistema de monitoramento que toma o crachá pela realidade preenche o inventário de segurança com uma informação errada.

A concessão foi feita aos aparelhos no trajeto. Alguns equipamentos intermediários haviam aprendido a estrutura da negociação antiga e falhavam ao receber valores novos. O Apêndice D.4 da RFC descreve um modo de compatibilidade: identificador de sessão não vazio enviado pelo cliente, mensagens ChangeCipherSpec fictícias e outros sinais de uma troca conhecida. Se os extremos escolheram TLS 1.3 pela extensão, o protocolo criptográfico em execução é TLS 1.3. A roupa antiga serve ao posto de passagem.

Esse posto exercia poder sem participar da decisão de segurança. Bastava descartar tráfego desconhecido para forçar o novo protocolo a mudar a aparência. A norma atendeu à exigência visual do equipamento instalado e preservou a escolha efetiva no campo lido pelos extremos. A aparência de uma mensagem e o estado da conexão passaram a exigir leituras diferentes.

O bilhete no fim do valor aleatório

Havia um risco mais severo do que a confusão de rótulos: alguém no caminho podia tentar empurrar os extremos para uma versão inferior. A RFC 8446 manda o servidor capaz de TLS 1.3 que negocia TLS 1.2 escrever 44 4F 57 4E 47 52 44 01 nos últimos oito bytes de ServerHello.random. Para TLS 1.1 ou abaixo, os sete primeiros bytes são iguais e o último é 00. Em ASCII, os sete primeiros formam DOWNGRD. O byte final distingue o grupo de versões antigas escolhido.

Ao receber um ServerHello que indique TLS 1.2 ou menos, o cliente TLS 1.3 precisa procurar os dois padrões. Se encontrar um, interrompe a negociação com illegal_parameter. Ele descobre que o servidor tinha capacidade para a versão mais nova embora a conversa tenha parado numa anterior. O simples sucesso de uma conexão velha não responde por que os dois lados deixaram de usar a versão superior disponível.

O alcance do aviso está no próprio texto. A RFC o chama de proteção adicional limitada ao intercâmbio Finished. Com cifras de chave efêmera, a assinatura na negociação antiga cobre os valores aleatórios; RSA estático não oferece a mesma defesa. O documento também observa que muitas implementações TLS 1.2 já instaladas não seguiriam a nova regra. Os oito bytes só denunciam algo quando o servidor capaz os emite e o cliente capaz os examina.

Outro aviso apareceu na segunda tentativa

A RFC 7507 enfrentou em 2015 uma situação diferente. Após uma falha, alguns clientes tentavam de novo com versão inferior para contornar incompatibilidades. Quem provocasse a falha podia estimular esse recuo. O cliente pode incluir TLS_FALLBACK_SCSV no novo contato; o servidor que aceita uma versão superior responde inappropriate_fallback. O registro TLS da IANA mantém o valor e o alerta.

O aviso de 2015 é levado pelo cliente que repete a tentativa. O de 2018 nasce no valor aleatório do servidor que conhece TLS 1.3. Cada um revela a capacidade conhecida de um participante num ponto diferente. Misturá-los num único rótulo de “proteção contra downgrade” esconde a pergunta mais importante: quem sabia da versão melhor quando a conexão voltou atrás?

A fantasia tinha um dono

O Apêndice D.4 registra a pressão dos aparelhos existentes sobre uma norma nova. O TLS 1.3 se pareceu o bastante com uma negociação anterior para passar. O marcador no aleatório do servidor traçou outra fronteira: uma concessão de aparência não entrega a um intermediário autorização para impor uma versão pior em silêncio. Os extremos mantiveram a decisão e um vestígio verificável do recuo de um servidor capaz.

Os documentos oficiais e o registro estabelecem as regras. Para mostrar que uma conexão específica usou o modo de compatibilidade e o marcador seriam necessários uma captura datada e registros das implementações cliente e servidor. O episódio de 2018 já é nítido: TLS 1.3 levou sua escolha verdadeira numa extensão, manteve o número antigo à vista e acendeu um aviso no fim do valor aleatório quando um servidor capaz recuou.