# What order should these HTTPS ciphers go in to maximize security?

I want to set up a very secure-from-MITM-attacks server. I have these algorithms enabled in my nginx and I'm getting an A+ on ssllabs.com but it's complaining that my cipher strength isn't 100% and that my key exchange isn't either. Even if reordering these won't improve it, I still would like to sort them by security level.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256  ECDH secp256r1  FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  ECDH secp256r1  FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256    DH 4096 bits    FS 128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384    DH 4096 bits    FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256  ECDH secp256r1  FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     ECDH secp256r1  FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384  ECDH secp256r1  FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     ECDH secp256r1  FS 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256    DH 4096 bits    FS 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA       DH 4096 bits    FS 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256    DH 4096 bits    FS 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA       DH 4096 bits    FS 256


If there is another change I need to make to fix my nginx setup I'm interested in learning that as well.

• Probably it would be better to ask this question one of the people at ssllabs - we can only speculate. But in general, some people think the suits with "DHE" are weaker (regardless of parameters), that's probably the issue. What also could be an issue: "_SHA" (without a number) indicates SHA-1 - which has a taste of 'expired'. – tylo Oct 26 '17 at 13:56
• @tylo: SHA1 is now officially broken for collision (and thus some/most signatures) but HMAC-SHA1 is unaffected because HMAC doesn't rely on collision resistance of the hash; see crypto.stackexchange.com/questions/26510/… – dave_thompson_085 Oct 27 '17 at 5:12
• @dave_thompson_085 Well, that is exactly what I meant. But if someone wants to achieve a high level of security, then SHA-1 should not be used in a cipher suite, even if it's just in the context of HMAC. And I speculate, that could be an evaluation criteria. – tylo Oct 27 '17 at 12:44

In short, don't bother getting 100 in "Cipher Strength" or "Key Exchange".

It is possible to get 100 in "cipher strength" by only allowing 256-bit ciphers, however, this will break compatibility with considerable amount of clients, slow down your server and have no security benefits. You can also get 100 in "key exchange" by only using >=4096-bit RSA or >=384-bit ECDSA certificate, as well as only allowing >=4096-bit DH or >=384-bit ECDH key exchange. I personally don't recommend it either for the same reason above.

There are some real things to do to improve security. If you are using OpenSSL 1.0.2 or lower, upgrade to 1.1.0 or higher, turn on ChaCha20 cipher and X25519 key exchange. Use 2048 or 3072-bit RSA and 256-bit ECDSA certificate in parallel if possible, and replace your DH parameter to match the length of your certificate key instead of 4096-bit.

The official document for NGINX SSL configuration: https://nginx.org/en/docs/http/ngx_http_ssl_module.html

By the way, SSL Labs will use a new letter-grade marking scheme and fully deprecate the numeric ones (https://blog.qualys.com/ssllabs/2017/06/30/ssl-labs-grading-redesign-preview-1). Therefore, in the future, getting a 100 will no longer make a difference.

Good luck!

• Thank you very much. Why does matching the DH length impact security? Also, how exposed am I without X25519 key exchange? – zachaysan Oct 26 '17 at 15:03
• Matching DH length for security with reasonable performance. If you use different lengths, the security will be constrained by the shorter one. Also, without X25519 you won’t have a problem except probably NSA. – zzq1015 Oct 27 '17 at 2:56