O artigo geral sobre forward secrecy (sigilo futuro) explica a propriedade: uma sessão tem forward secrecy quando o segredo dela foi derivado de uma troca de chaves efêmera ( ou ), e não criptografado com a chave de longo prazo do servidor. No F5 BIG-IP, essa propriedade não é uma opção que você liga: quem decide é a configuração de cifras associada ao profile SSL que termina a conexão. Este artigo complementar mostra onde fica essa configuração e como fazer da forward secrecy um resultado garantido, e depois comenta como o mesmo trabalho é feito em Fortinet e Netskope.

Onde a decisão é tomada

No BIG-IP, a forward secrecy depende de quais cipher suites (as suítes de cifras) o profile SSL do lado do cliente aceita negociar, e da ordem em que ele as prefere. O profile Client SSL tem uma configuração de cifras, e é o token de troca de chaves da cipher suite negociada (a parte do nome que indica a troca de chaves) que determina a forward secrecy, exatamente como o artigo geral descreve. Se o profile permite e prefere suites ECDHE (ou DHE), as sessões têm forward secrecy; se ele permite suites de transporte de chave com RSA estático (as que têm o nome começando com TLS_RSA_WITH_) e um cliente as prefere, essas sessões não têm. Garantir forward secrecy, portanto, é montar a lista de cifras de modo que a troca de chaves efêmera seja oferecida e o transporte de chave com RSA estático fique excluído ou com prioridade mais baixa.

O BIG-IP moderno faz isso com cipher rules e cipher groups, e não com uma única string opaca. Uma cipher rule define uma cipher string ordenada e, opcionalmente, restrições de grupo (Diffie-Hellman) e de assinatura; um cipher group combina rules com as ações allow, restrict e exclude para chegar à lista final. A forma mais antiga é uma cipher string escrita direto no profile: uma lista ordenada de cipher sets (conjuntos de cifras) separados por dois-pontos, em que as palavras-chave se combinam com +, um ! na frente exclui, um - apaga e @STRENGTH reordena pelo tamanho da chave. Nos dois casos, a mecânica é a mesma: você está montando o conjunto ordenado de suites que o profile vai negociar, e a forward secrecy fica garantida quando esse conjunto tem suites com troca de chaves efêmera e não cai para RSA estático. Como a lista exata de suites, depois de expandida, depende do banco de dados de cifras do TMOS de cada versão, vale a pena confirmar o resultado em vez de presumir; a ferramenta cipher-string-expander explica o que uma rule ou uma string significa e aponta escolhas fracas ou obsoletas, e no próprio equipamento o tmm --clientciphers <string> mostra a lista ordenada que um profile ofereceria de fato.

Por que a preferência do lado do servidor importa

Escolher quais suites são permitidas é só metade do trabalho; é a ordem que decide qual delas será escolhida de fato. Na negociação, o cliente oferece uma lista e o servidor escolhe. Por padrão, o servidor pode respeitar a ordem de preferência do cliente, e aí um cliente que prefere uma suite mais fraca, ou sem forward secrecy, consegue levar a sessão para ela mesmo havendo opções melhores. Habilitar a preferência de cifras do servidor (server cipher preference, para que a ordem do próprio BIG-IP prevaleça) é o que permite aplicar de verdade uma política de ordenação: coloque as suites ECDHE- primeiro, e o servidor vai escolhê-las sempre que o cliente as suportar, seja qual for a ordem do cliente. Esse é o assunto do artigo complementar sobre ordenação e negociação de cifras, e é a diferença entre "há suites com forward secrecy disponíveis" e "as suites com forward secrecy são usadas".

O TLS 1.3 elimina a escolha

A forma mais limpa de garantir forward secrecy é preferir o TLS 1.3 no lado do cliente. Como explicam o artigo geral e o artigo sobre TLS 1.3, o TLS 1.3 tirou do protocolo, por completo, o transporte de chave com RSA estático; toda troca de chaves do TLS 1.3 é efêmera, então qualquer sessão negociada em 1.3 tem forward secrecy garantida, sem nenhum ajuste de cifras. A configuração de cifras passa a valer só para o fallback para TLS 1.2, que é onde a disciplina de usar ECDHE em vez de RSA estático ainda se aplica, para os clientes que não suportam 1.3. Como visto no artigo sobre os profiles Client SSL e Server SSL, os dois profiles têm configurações de cifras independentes; por isso, uma revisão de hardening confirma a forward secrecy no lado do cliente e, separadamente, no lado em que o tráfego é criptografado de novo até o backend.

O mesmo trabalho em Fortinet e Netskope

O princípio não depende de fabricante; só muda o lugar onde se faz o controle. Num FortiGate, as configurações de inspeção SSL/ e as configurações SSL do ou do server-load-balance mostram as cipher suites e as versões de TLS permitidas, e garantir forward secrecy significa permitir suites ECDHE e desabilitar o RSA estático e as versões obsoletas do protocolo; aqui também, preferir o TLS 1.3 deixa isso automático. No Netskope, a terminação TLS acontece no data plane na nuvem, então a política de cifras é uma configuração do tenant, e não um profile por equipamento: a plataforma negocia suites modernas, com forward secrecy, com os clientes e com os destinos, e o que o administrador controla é a versão mínima de TLS e a política de descriptografia, e não uma cipher string escrita à mão. Em todos os casos, a regra básica do artigo geral continua valendo: há forward secrecy exatamente quando a troca de chaves negociada é efêmera, e cada produto só oferece um jeito diferente de garantir esse resultado.

Fontes

A metade de protocolo disto é normativa e a metade de configuração é da F5, portanto impor sigilo futuro tem uma fonte para o porquê e outra para o onde.