2

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).

  • why would a CDN be affected by a site policy? how secret is the stuff on the CDN? can you not use the integrity attrib on pages loading CDN resources? I also don't see the problem with sha in a cipher suite, but that's something else... – dandavis Aug 11 '16 at 20:36
  • Because ALL traffic passes through the CDN (think of it as a reverse proxy) - public TLS connections are made to the CDN. It's not possible for the outside world to connect directly to the origin. – Mark Kelly Aug 11 '16 at 20:41
3

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.)

3

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
  • The industry isn't making an effort to move from 128- to 256-bit AES on its own. They have to move to post-quantum ciphers eventually, but there's little reason to do it before deploying post-quantum key exchange algorithms, and that isn't going to happen soon. – Matt Nordhoff Aug 11 '16 at 21:39
  • Aria - I'm not entirely convinced by your reasoning, but the tip about using nmap to enumerate the installed cipher suites is very helpful. – Mark Kelly Aug 11 '16 at 22:43
  • It's dump from Fedora 24 Server, and I am pushing it like this to live systems and it's working just fine, so it's latest Redhat standard. Also, this Fedora uses OpenSSL 1.0.2h-fips so there's no ChaCha20-Poly1305 in it yet (it's in OpenSSL 1.1.0 which is still in beta). – Aria Aug 11 '16 at 23:03
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.