Tentando obter 100% na troca de chaves do ssllabs.com

Question

Eu queria saber quais etapas são necessárias para obter 100% de todas as categorias no ssllabs.com. Estou ciente de que isso pode levar a problemas em sistemas mais antigos, mas eu não me importo.

Meu certificado letsencrypt.org usa 4096 bits. Esta é a melhor pontuação que consegui usando a seguinte configuração:

SSLCipherSuite AES256+EECDH:AES256+EDH:!aNULL
SSLHonorCipherOrder on
SSLProtocol all -TLSv1.1 -TLSv1 -SSLv3 -SSLv2

Euli em algum lugar que a troca de chaves poderia ser melhorada usando um arquivo pré-gerado arquivo dhparam.

Então eu gerei esse arquivo usando openssl dhparam -out dhparam.pem 4096 (isso levou cerca de uma hora) e o adicionei à minha configuração do Apache usando

SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

mas isso resulta na mesma pontuação de antes. Então, o que estou perdendo aqui?

Resultado completo do ssllabs.com

    

Answer 1

A partir de 2017-10, se você estiver usando o Diffie-Hellman, você deve ter os parâmetros DH e com RSA equivalentes a 4096 bits.

Você está oferecendo pelo menos um certificado para uma chave de 2048 bits. Você também está tendo metadados incomuns nesse certificado, verifique se (o certificado padrão de óleo de cobra para dizer "não atendo clientes não-sni" geralmente tem apenas o nome do host em Common Name )

Editar: Você não será penalizado na classificação SSL Labs por certificados que você não oferece exclusivamente a clientes não-SNI. Você também não será penalizado por certificados com chaves fracas fornecidos como parte de sua cadeia de certificados para uma raiz conhecida.

Você encontrará a documentação completa sobre a classificação no ssllabs conta do github.

For suites that rely on DHE or ECDHE key exchange, the strength of DH parameters is taken into account when determining the strength of the handshake as a whole. Many servers that support DHE use DH parameters that provide 1024 bits of security. On such servers, the strength of the key exchange will never go above 1024 bits, even if the private key is stronger (usually 2048 bits).

O guia de classificação não diz, mas eu pude confirmar que você não pode obter a classificação 100 se seu servidor preferir secp256v1 (equivalente a 3k bits RSA) enquanto oferece cifras ECDHE que poderiam estar usando secp384v1 (equivalente a 7k bits RSA).

Chrome 57 / Win 7
R
RSA 4096 (SHA256)
TLS 1.2 > http/1.1
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   
ECDH secp256r1  FS

O manual do Apache lista uma opção para forçar isso (simplesmente ordenar o parâmetro Curves por força parece ser insuficiente)

Compatibility: Available in httpd 2.4.8 and later, if using OpenSSL 1.0.2 or later SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1

link

Se você nomear uma curva aqui que possa ser considerada equivalente a RSA > = 4096 bits, os laboratórios ssl usarão isso para suas cifras ECDHE - listando os clientes que não podem mais obter um handshake com seu servidor porque eles não conseguem mais não suporta essa curva.

Analise cuidadosamente a lista de navegadores que você deseja oferecer, escolhendo uma curva EC não padrão que tornará seu site inacessível para muitos navegadores mais antigos!