I performed SSL test on development server: "SSL Report v1.15.1" and I see Android 5.0 has performed test with CBC cipher and Android 4.4 with GCM. Is this really correct? I see GCM ciphers stronger then CBC, so this is why I think this is strange.
See test result
This is because Android 4.4 supports 256-bit AEAD GCM, and Android 5.0 supports 256-bit, but only CBC. This is an intentional regression.
That server should enable 128-bit AEAD GCM and prioritize it.
just to give a bit more detail, android 5.0 disabled AES-256 GCM to be more closely aligned with what google chrome supports. there's talk about disabling AES-256 CBC in chrome (and probably in android as well) in the future. so if you want those clients to be able to access your site, you'll need to enable either AES-128 GCM or chacha20-poly1305.
What is the reasoning behind these changes?
Issue 442572 - chromium - Disable AES-256-CBC modes by default - An open-source project to help move the web forward.…
From above link to recap in my humble opinion the most interesting info:
On a scale of security AND speed
128-GCM > 128-CBC
128-GCM > 256-CBC
128-GCM ~ 256-GCM (again, we are counting both performance and effective security here)
However, a number of servers are poorly configured, where the administrator has configured the server to believe that 256 bit ciphers in any block mode are always better than 128-bit. This is wrong. 128-GCM is far, far more desirable than 256-CBC.
raymii.org and cipherli.st are exactly examples of the misbelief mentioned by Ryan. SSL Labs should penalize CBC mode block ciphers to correct the misbelief.
It looks like now SSLlabs.com test gives 100% for cipher strength if 256-bit ciphers are used and less then 100% if one of the 128-bit like 128-GCM is used. In my humble opinion in SSLlabs.com test this additional numbers e.g. 100% at "cipher strength" are little bit confusing and encourage non-optimal configuration. I think it would even be better to remove this 100% numbering completely, because grading from A+, A, B etc is good enough for security.
I agree. Although I not nessesairy agree with Google/Chromium that 256bit AES is not worth the performance gain, I don't think using 128bit only should result in a less than maxium score. It is performance discussion and not so much a security issue. On mobile - hence Android - the tradeoff can be different than desktop for instance.
For similar arguments I would not however agree with an assertion that using CBC should be penalized. I know that is a bit of a pet-issue from Google's Adam Langley, but CBC modes are fine as long as some attacks - which are mostly theoretical anyway - against timing are handled. And all mayor vendors have done that. So whiel GCM is prefered, CBC is just fine. More generic, I've said it in a different context, but I see mostly value in SSL Labs as a security scanner, and not a feature test. Of course listing all features and making recommendations is great, but reducing score for using something which is safe but just not the very-latest (GCM vs CBC) or theoretical best (256 vs 128) would reduce the value of the test IMHO.
Thank you for your answers and suggestions. I now added AES-GCM-128 to cipher list.
@Ar Gerrit, I agree that SSL Labs should not penalize the very good security (CBC) vs. edge security (GCM) in the way that CBC gets lower grade or something. But in current test it is actually the opposite it rewards AES-CBC-256 with 100% Cipher Strength and it penalizes the AES-GCM-128 with 90% Cipher Strength. My suggestion was to keep Overal Reating and just drop this percentages bars on the right, because they can get confusing and even misleading; or in case of preserving not only evaluate bitnes of cipher as the only criteria. Maybe it would be best to create some virtual cipher groups and reward the best with 100% Cipher Strength, then next group of ciphers that get 90% etc and the cipher which belongs to lower graded group would get the Cipher Strength percentage grade.
Retrieving data ...