Allow better cipher strength score with GCM AES128 (mandatory in HTTP/2)

[fdelapena]

It is technically impossible to handle 100% score in your server test by properly implementing HTTP/2 in TLS 1.2 according to RFC 7540, which mandates to support this cipher. The scanner could be adjusted when the honored cipher order with higher GCM ciphers negotiating before this mandatory one and also always before any other CBC. As mentioned in other issues, GCM even with AES128 should score better than CBC with AES256. This would prevent server misconfigurations due to bad advices in your scanner. Thanks.

[zzq1015]

https://github.com/ssllabs/research/wiki/SSL-Labs-Assessment-Policy-v2017 Hopefully SSL Labs will get rid of the numeric scoring. In my opinion, cipher ordering should be like this:

ECDHE + ChaCha20-Poly1305 (if preferred by client)
ECDHE + AES-GCM
DHE + AES-GCM
ECDHE + AES-CBC + HMAC-SHA1
ECDHE + AES-CBC + HMAC-SHA2
DHE + AES-CBC + HMAC-SHA1
RSA + AES-GCM
RSA + AES-CBC + HMAC-SHA1

If you need compatibility with IE 6-8 in Windows XP, add RSA + 3DES + HMAC-SHA1

[ArchangeGabriel]

I only use the first two. :) It helps to be your only “client”. ;)

[joramk]

This is also true for TLS 1.3. draft-ietf-tls-tls13-28 RFC says:

9.1. Mandatory-to-Implement Cipher Suites

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites.

[wibimaster]

Yep, cannot get 100% cipher strength after TLS 1.3 implementation..

[snapercloud]

+1

[WebGuyJeff]

This is still true. It will encourage implementers to avoid 128-bit ciphers. OpenSSL/Nginx seem to have baked the TLS_AES_128_GCM_SHA256 cipher into the active list meaning it can't be disabled through conventional CLI commands or configs - not that you should for production purposes anywho. Perhaps the guys at SSL Labs are a glass 90% full kinda crowd.