Resumo

  • A RFC 3268 não substituiu a negociação do TLS. Ela inseriu doze identificadores AES no menu existente: seis formas de troca/autenticação para cada um de dois tamanhos de chave.
  • AES-256 não autentica o servidor nem cria sigilo futuro por conta própria. Isso depende do handshake escolhido e de sua implementação.

A cifra precisava caber numa escolha compartilhada

Transformar AES em padrão não bastava para que cliente e servidor TLS conseguissem negociar seu uso. Ambos precisavam falar dos mesmos parâmetros com nomes comuns. O TLS 1.0 já fornecia esse mecanismo: o cliente apresentava uma lista de suítes no ClientHello, e o servidor escolhia uma suportada. A RFC 2246 definia cada suíte como uma combinação de troca de chaves, cifra dos dados e algoritmo de autenticação de mensagens.

Publicada em junho de 2002, a RFC 3268 encaixou AES nessa estrutura. Ela especificou AES em CBC com HMAC-SHA-1, mas não como opção isolada. Eram seis famílias de handshake: RSA; DH estático com certificado DSS ou RSA; DHE efêmero assinado por DSS ou RSA; e DH anônimo. Cada uma aparecia com chave AES de 128 ou 256 bits. O resultado: doze identificadores.

Essa matriz manteve diferenças essenciais. RSA, DH autenticado e DH anônimo não se tornam equivalentes porque usam a mesma cifra de bloco. DHE pode oferecer sigilo futuro se as chaves efêmeras não forem reutilizadas, forem destruídas com segurança e vierem de um gerador aleatório adequado. DH anônimo não autentica o par e deixa espaço para ataque de intermediário, a menos que outra técnica vincule as partes ao mesmo Finished do TLS. O tamanho da chave AES não resolve essas questões.

O AES permite chaves de 128, 192 e 256 bits; a RFC escolheu apenas 128 e 256 para conter a proliferação de nomes. Todas as suítes usavam blocos de 128 bits: uma chave maior não muda o tamanho do bloco. CBC e SHA-1 no HMAC também faziam parte da definição. “AES” era apenas um elemento do pacote negociado.

Compatibilidade significou mais combinações para governar

A introdução da RFC observou que as suítes DHE existentes se concentravam em triple-DES, além de variantes de exportação com chaves inadequadas. AES entrou sem exigir outro ClientHello ou uma nova negociação no TLS 1.0. Em contrapartida, cada combinação ganhou código, nome, preferência e obrigação de implementação.

Um código na IANA não demonstra que produtos o suportaram, preferiram ou negociaram. A arquitetura posterior ajuda a enxergar o movimento: no TLS 1.2, muitas suítes ainda agrupavam vários componentes; no TLS 1.3, a suíte identifica AEAD e hash, enquanto grupos de troca de chaves e algoritmos de assinatura são negociados em separado. A RFC 3268 registra, portanto, uma mudança na localização das decisões do TLS, não apenas a chegada de um algoritmo.

Seu valor histórico está em expor uma fronteira de controle. Algoritmo, tamanho de chave, autenticação, troca de chaves e proteção de registros respondem a perguntas diferentes. Uma suíte é um conjunto negociado; usar uma palavra do nome como resumo de segurança confunde um componente com a conexão inteira.

Fontes