Como tornar o TLS “moderno” e os navegadores “desatualizados” amigáveis?

O tópico foi estimulado por uma discussão do post anterior , em que a voz de um administrador de servidor web atencioso soou: TLS 1.2 e AEAD são a escolha de uma pessoa saudável, mas quem se arrependerá de usuários de navegadores "desatualizados"? Vamos discutir isso - a alegada incompatibilidade entre o TLS "moderno" e os navegadores "legados".



A hipótese é a seguinte: se apenas as versões estáveis ​​do protocolo de segurança da camada de transporte TLS (1.2 e 1.3) e dos pacotes de criptografia (AEAD) forem deixadas no servidor web, os usuários de navegadores "desatualizados" não conseguirão acessar o site.



Vamos fazer uma excursão opcional pela história ... Em 2005 (ou seja, 16 anos atrás), a Agência de Segurança Nacional dos Estados Unidos anunciou um corpus de padrões, diretrizes, recomendações e outros documentos de apoio sobre o uso de algoritmos criptográficos - NSA Suite B Cryptography.



Em 2009, a IETF publicou RFC5430Perfil do Suite B para Transport Layer Security, que estabeleceu quais protocolos e pacotes de cifras devem ser usados ​​para conexões HTTPS a fim de cumprir os requisitos de NSA. Mesmo assim, para atender a esses requisitos, o servidor da web e o navegador da web tinham que suportar o TLS versão 1.2 e os conjuntos de criptografia TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 e TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.



Ou seja, há pelo menos 11 anos, os desenvolvedores sabem quais requisitos seus produtos devem atender para poderem se qualificar para um pedido do governo americano. Portanto, você provavelmente perceberá o seguinte fato sem surpresa: todos os navegadores realmente usados ​​hoje suportam o conjunto de cifras mencionado na versão com uma chave de cifra de 128 bits, e muitos (mas não todos) - e com um de 256 bits.



Este pode ser o final do artigo, recomendando que todos os administradores de servidor web deixem o suporte apenas para TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 e não se preocupem com mitos sobre a incompatibilidade do TLS 1.2 com navegadores "desatualizados", se não por uma nuance: nas versões TLS anteriores a 1.3, o algoritmo de assinatura digital deve estar em cifra coincidir com o algoritmo no certificado TLS e menos de 6% dos servidores web com um certificado assinado usando o algoritmo ECDSA na zona de domínio .RU , o restante é usado para assinatura RSA.



Quem é o culpado é uma questão de estudo separado; estamos interessados ​​no que fazer? Vamos primeiro lembrar que não apenas a combinação ECDHE + ECDSA + AES recomendada pela NSA, mas também outras estão entre os conjuntos de criptografia fortes hoje:





Um total de 19 suítes de criptografia fortes, mas nem todos são adequados para uso na vida real em um servidor web público: o algoritmo de criptografia CAMELLIA, como AES no modo CCM, é suportado por pouco mais do que qualquer pessoa, com CHACHA20 e seus fiéis acompanhantes POLY1305 são apenas navegadores modernos relativamente familiares e, para usar conjuntos de criptografia baseados em ECDSA, como já mencionado, é necessário um certificado TLS apropriado. Portanto, temos apenas 4 conjuntos de criptografia "adicionais"



restantes : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.



É tentador supor que, se o navegador suportar a combinação ECDHE + ECDSA, então ele definitivamente lidará com ECDHE + RSA, mas nem sempre é o caso - muitos só podem fazer DHE + RSA, e para satisfazer as solicitações de todos os navegadores antigos, em um site com um certificado RSA, você precisa oferecer suporte a dois conjuntos de criptografia:



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Isso nos dará compatibilidade com pelo menos os seguintes sistemas operacionais e navegadores:



Android 4.4.2 + Navegador Android (Chrome);

Windows XP + Chrome 49 / Firefox 49 / Opera 12.18;

Windows 7 + Internet Explorer 11 / Chrome 31 / Firefox 31;

OS X + Firefox 29 / Chrome 37;

iOS 9 + Safari 9;

Java 8b.



Não direi sobre sistemas * nix - depende da montagem, mas é óbvio que o problema não existe como tal. O único problema surgirá com o Windows Phone 8.1 + IE 10, que suporta apenas uma combinação estável - ECDHE + ECDSA.



Mas o que os usuários do Windows XP + IE 6 ou de alguns Android 2.3 devem fazer? - o administrador atencioso perguntará. Continuarsente-se sem acesso à Internet moderna, - responderei, - porque nem mesmo o suporte do protocolo de servidor web SSL 2.0 os ajudará. O fato é que mesmo que você implemente no Windows XP todas as atualizações lançadas para ele (até maio de 2019) e atualize o navegador padrão para a versão 8, isso só trará suporte para TLS 1.2, mas não para suítes de cifras estáveis. Além disso, o Windows XP não sabia nem aprenderia o que são Server Name Indication (SNI), HTML 5 Live HTML e CSS 3.



Você está pronto para os teimosos "escavadores e meio" para manter um IP dedicado para o site e não atualizar o layout? Em seguida, adicione suporte, por exemplo, TLS_RSA_WITH_AES_256_CBC_SHA256, mas, em vez disso, você deve assumir que um usuário moderno do Windows XP há muito usa um navegador alternativo que até suporta TLS 1.3. O mesmo é verdade para o Android 2.3, instalando o Firefox 27 no qual teremos suporte total para suítes de cifras TLS 1.2 e AEAD, e sem instalar - simplesmente não poderemos usar uma parte significativa dos sites modernos, mesmo via HTTP.



Tudo isso, é claro, não é uma chamada para abandonar o suporte para conjuntos de criptografia mais fortes, que serão exigidos pelos navegadores modernos e que devem ser propostos para negociação em primeiro lugar.



Para não se levantar duas vezes, considere brevemente a situação com curvas elípticas. A criptografia NSA Suite B reconhece apenas dois deles - NIST P-384 e NIST P-256, suporte para o qual no servidor web fornecerá acesso ao site para navegadores modernos e "legados". Na verdade, é o suficiente para suportar apenas NIST P-384 para "mais antigos" e Curve25519 para navegadores modernos; bem, exceto talvez para adicionar NIST P-521, para alguns "antigos avançados".



Para resumir: se quisermos que o site permaneça acessível para navegadores "desatualizados", mas ao mesmo tempo suporte apenas versões estáveis ​​do protocolo de segurança da camada de transporte e suítes de criptografia, procederemos da seguinte maneira.



Para um site com um certificado TLS assinado usando o algoritmo ECDSA, ative o suporte para o conjunto de criptografia TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.



Para um site com um certificado TLS assinado usando o algoritmo RSA , ative o suporte para os conjuntos de cifras TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 e TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Para ambos os sites, vamos ativar o suporte para a curva elíptica NIST P-384 ou NIST P-256 e definir a ordem de preferência para conjuntos de cifras e curvas elípticas, de acordo com a qual os conjuntos e curvas acima são oferecidos aos navegadores para correspondência depois de mais os estáveis, por exemplo, após TLS_ECDHE_RSA_WITH_AES_ 256 _GCM_SHA 384 e Curve25519, respectivamente.