Excluding cipher suites containing SHA or AES128

Question

I’m aware this might not be seen as a question, but here goes:

A large organisation I work with has recently issued a new set of standards for acceptable cipher suites on all of their public-facing websites. The standards boil down to this:

• If the cipher suite contains SHA1 - it’s not acceptable (e.g. ECDHE-RSA-AES256-SHA)
• If the cipher suite uses 128bit encryption - it’s not acceptable (e.g. ECDHE-RSA-AES128-GCM-SHA256)

As far as I can tell, even with any recent vulnerability findings, this doesn’t seem like a sound premise for a set of TLS standards. HMAC with SHA is still considered acceptable, and AES128-GCM is considered pretty robust (as far as I know).

I have one chance to argue for an exception to this rule (which I’d like to do, as compliance involves removal of a major CDN provider from the site). Does anyone have any thoughts on why removal of cipher suites meeting these criteria would be detrimental to the end user of the site (client compatibility, performance etc).

Answer 1

First, it's unnecessary from a security point of view. HMAC-SHA1 and AES-128 are more or less alright. This is silly. Don't write silly security policies.

Second, you'd screw Firefox. Firefox 46 supports AES-128 with HMAC-SHA1 or GCM, and AES-256 with HMAC-SHA1. AES-256-GCM is not an option.

Firefox 47 also added ChaCha20-Poly1305, which is a great 256-bit cipher, but it's quite new, not widely supported by servers, and you didn't mention it.

Firefox 49, currently scheduled for release September 13, should get AES-256-GCM, but that's in the future, and you'll want to continue supporting older versions for gods know how long anyway.

Third, there is a good reason to prefer non-HMAC cipher suites: HTTP/2 encourages it. Implementing the cipher suite blacklist is optional, but Chrome and Firefox both do so. If you enable HTTP/2, you'll absolutely need acceptable cipher suites (which include AES-GCM with DHE or ECDHE key exchange, but not HMAC, regardless of the key size). You're free to keep obsolete cipher suites enabled, but you have to give preference to better ones when negotiating with HTTP/2 clients.

ETA: You could point them to Mozilla's Server Side TLS guide and SSL Configuration Generator and say "It's a good idea to copy this solid, well-researched expert recommendation." It would be true, and it would keep AES-128 support. (Some variants actually do remove HMAC-SHA1, but they all keep HMAC-SHA256 and HMAC-SHA384.)

Answer 2

The upgrade to AES-256 is happening and new servers offer it as 1-st option. To illustrate you how this is done here is list of newer httpd SSL ciphers (test with nmap), see below.

Now the thing is that if browser would not be able to use any strong variant then it can use any other weaker supported cipher. Ciphers are tried from the highest TLS protocol supported and then variants from the top first to the bottom last.

The following configuration makes good clients using strong ciphers but keeps compability with older ones so no-one is affected.

After change to that, one can analyze SSL logs to see what variants can be removed and how many users will be affected, but if it's big company then the list below should work for everyone for the start.

Regarding CDNs, to do switch from AES-128 to 256 is huge change which costs significant $$$. However, such change will have to happen once they upgrade the software to the newer one which will surely happen in the coming years.

So with this server Firefox is using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, OpenSSL is using best choice TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Google Chrome says TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA, all with TLS 1.2.

Doing it differently will upset many users.

nmap --script ssl-enum-ciphers -p 443 127.0.0.1

443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|_  least strength: C

Answer 3

You could make the argument that removing SHA1 and 128-bit encryption will cause compatibility issues, even though SHA1 is currently being phased out. Advice them to rely on NIST for algorithm choices.