Looking at the Qualys cert as an example, Chrome indicates the cipher suite is obsolete. What is it that Chrome thinks is insecure even on pages where Qualys indicates an A or A+?

Looking at the Qualys cert as an example, Chrome indicates the cipher suite is obsolete. What is it that Chrome thinks is insecure even on pages where Qualys indicates an A or A+?

Sorry, I'm a little confused. You are saying many sites

**dont**support AEAD cipher suites which is unfortunate, but that google says anything less than TLS 1.2 with AEAD is insecure. Could you clarify that? What is weird to me is Gmail gets a B on SSL Labs due to support for RC4, insecure cipher suites, etc. So it seems like some disagreement on what is most secure?Anything other than TLS >= 1.2 with AEAD == theoretically broken. Google still supports RC4 and SSL3 so that very outdated clients are still able to connect, but this is going to change soon.

Of course, the fact that Google also supports obsolete cipher suites allows anyone to disable modern suites in their Chrome by using command line parameter and open Google without problems, and also make funny screenshots about "obsolete" warnings on Google itself.

Anything other than TLS >= 1.2 with AEAD == theoretically broken.

If I understand correctly only "Mac=AEAD" in combination of TLSv1.2 are the ones which are secure by the Adam's recommendation. To get this ciphers:

**openssl ciphers -v 'ALL' | grep 'TLSv1.2' | grep "Mac=AEAD"**or because all of AEAD ciphers only works with TLSv1.2 just:

**openssl ciphers -v 'ALL' | grep "Mac=AEAD"**ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD

DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD

DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD

ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD

ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD

AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD

ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD

DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD

DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD

ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD

ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD

ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD

AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD

and some of them do not support Forward Secrecy (the ones not starting with ECDHE or DHE).

Is this correct list of ciphers that is allowed? Looking at the SSLlabs test I can't see this information in

**Cipher Suite**section. It would be nice if this info is displayed in test, maybe next to "FS", like "AEAD".Now is the next question, what do you think should SSLlabs start lowering the grade for those that do not comply like not getting A+ grade?

And on top of this, some consider AES256 worse than AES128 because of timing attacks known to some implementations.

Some consider non-FS broken.

Some consider DHE broken, some just say you have to use custom, long parameters (primes).

Some consider ECDHE broken due to the currently supported –probably backdoored– curves to choose your session key from. Some consider ECDSA keys broken for the same reason.

DSS is not available in modern browsers anymore.

What keeps us with …?

Not quite. The padding used in a CBC cipher suite is generally what gets hit the most, whether it be down to design or implementation. Whilst RC4 is such a poor method of encryption that it can be reasonably brute-forced, POODLE, POODLE-TLS, BEAST and, most importantly, the Lucky Thirteen attack all take advantage of the fact that CBC cipher suites have a weakness big enough to make some attacks feasible in certain circumstances. This is a problem that is fixed by both GCM and ChaCha/Poly cipher suites. The list of "secure" cipher suites is as follows:

AES GCM

AES CCM

AES CBC with TLS 1.1 and later

Camellia GCM

Camellia CBC with TLS 1.1 and later

ARIA GCM

ARIA CGC with TLS 1.1 and later

SEED CBC with TLS 1.1 and later

GOST 28147-89 CNT (the only currently always-secure option for TLS 1.0)

IDEA CBC with TLS 1.1

ChaCha20-Poly1305

Additionally, with certain mitigations in place, the following

*can*be secure:AES CBC with TLS 1.0

Camellia CBC with TLS 1.0

ARIA CBC with TLS 1.0

SEED CBC with TLS 1.0

IDEA CBC with TLS 1.0

3DES EDE CBC is secure-but-low-strength with TLS 1.1 and later, and secure-but-low-strength with certain mitigations in place with TLS 1.0.

Anything using SSL 2.0 or SSL 3.0 is insecure. DES CBC, RC2 CBC, RC4 and null cipher suites are insecure.

This is a completely different discussion to whether or not something is cryptographically broken, which is a phrase that means the best (and only) attack is a brute-force attack. As soon as there is any way to attack the cipher suite more quickly than using brute force, the cipher suite is cryptographically broken. This means that TLS_NULL_WITH_NULL_NULL is technically not cryptographically broken - there is no cryptography to break. It obviously isn't secure, however. Despite what Adam Langley says, AES GCM suites actually

*are*cryptographically broken as there's a biclique attack reducing AES-128 from 128 bits to 126.2 bits. But they're very secure. I think ChaCha20/Poly1305 is the only cryptographically unbroken cipher suite implemented in mainstream client and server technologies in widespread use, and that's likely only because it's not very old.Furthermore, forward secrecy is important. This is not to do with strength of encryption, but simply to do with protecting against losing a private key. If you can assume that the attacker will never find out the private key then forward secrecy has no advantage, but given that it's an obvious defence, you should use it. DHE has a feasible brute-force attack for smaller primes, but becomes "secure" with larger primes because the attack is a brute-force attack, even if it's a very clever one. ECDHE has no known attacks but those in tinfoil hats worry about the elliptic curves used. DH and ECDH are not widely supported either server or client side, as why would you when you could use DHE and ECDHE instead? DSS keys are considered insecure as they're effectively limited to 1024 bits. So with a few exclusions due to browser support, and the fact that PSK/SRP/KRB5 etc. wouldn't be used for public connections, with end up with the following cipher suites still being considered "secure" (i.e. no

*practical*attacks, given sufficient key strengths) over TLS 1.0, 1.1 and 1.2, assuming that the 1/n-1 splitting on the client side is in place for TLS 1.0 CBC suites:0xC0,0x2C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9D TLS_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9C TLS_RSA_WITH_AES_128_GCM_SHA256 0xC0,0xAD TLS_ECDHE_ECDSA_WITH_AES_256_CCM 0xC0,0xAC TLS_ECDHE_ECDSA_WITH_AES_128_CCM 0xC0,0xAF TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 0xC0,0xAE TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 0xC0,0x9F TLS_DHE_RSA_WITH_AES_256_CCM 0xC0,0xA3 TLS_DHE_RSA_WITH_AES_256_CCM_8 0xC0,0x9E TLS_DHE_RSA_WITH_AES_128_CCM 0xC0,0xA2 TLS_DHE_RSA_WITH_AES_128_CCM_8 0xC0,0x9D TLS_RSA_WITH_AES_256_CCM 0xC0,0xA1 TLS_RSA_WITH_AES_256_CCM_8 0xC0,0x9C TLS_RSA_WITH_AES_128_CCM 0xC0,0xA0 TLS_RSA_WITH_AES_128_CCM_8 0xC0,0x24 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 0xC0,0x0A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0xC0,0x23 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 0xC0,0x09 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0xC0,0x28 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 0xC0,0x14 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xC0,0x27 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 0xC0,0x13 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0x00,0x6B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 0x00,0x39 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0x00,0x67 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 0x00,0x33 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x00,0x3D TLS_RSA_WITH_AES_256_CBC_SHA256 0x00,0x35 TLS_RSA_WITH_AES_256_CBC_SHA 0x00,0x3C TLS_RSA_WITH_AES_128_CBC_SHA256 0x00,0x2F TLS_RSA_WITH_AES_128_CBC_SHA 0xC0,0x87 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x86 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x8B TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x8A TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x7D TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x7C TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x7B TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x7A TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x73 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 0xC0,0x72 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 0xC0,0x77 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 0xC0,0x76 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 0x00,0xC4 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 0x00,0x88 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0x00,0xBE TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 0x00,0x45 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0x00,0xC0 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 0x00,0x84 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0x00,0xBA TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 0x00,0x41 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 0xC0,0x5D TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x5C TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x61 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x60 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x53 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x52 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x51 TLS_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x50 TLS_RSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x49 TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384 0xC0,0x48 TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256 0xC0,0x4D TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384 0xC0,0x4C TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256 0xC0,0x45 TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384 0xC0,0x44 TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256 0xC0,0x3D TLS_RSA_WITH_ARIA_256_CBC_SHA384 0xC0,0x3C TLS_RSA_WITH_ARIA_128_CBC_SHA256 0x00,0x9A TLS_DHE_RSA_WITH_SEED_CBC_SHA 0x00,0x96 TLS_RSA_WITH_SEED_CBC_SHA 0x00,0x07 TLS_RSA_WITH_IDEA_CBC_SHA When the ChaCha20/Poly1305 cipher suites are finalised and registered, they will be added to the list. However, if you're looking to avoid implementation bugs leaving you open to practical attack, this list gets dramatically shorter (but again will include ChaCha20/Poly1305 when finalised):

0xC0,0x2C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9D TLS_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9C TLS_RSA_WITH_AES_128_GCM_SHA256 0xC0,0xAD TLS_ECDHE_ECDSA_WITH_AES_256_CCM 0xC0,0xAC TLS_ECDHE_ECDSA_WITH_AES_128_CCM 0xC0,0xAF TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 0xC0,0xAE TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 0xC0,0x9F TLS_DHE_RSA_WITH_AES_256_CCM 0xC0,0xA3 TLS_DHE_RSA_WITH_AES_256_CCM_8 0xC0,0x9E TLS_DHE_RSA_WITH_AES_128_CCM 0xC0,0xA2 TLS_DHE_RSA_WITH_AES_128_CCM_8 0xC0,0x9D TLS_RSA_WITH_AES_256_CCM 0xC0,0xA1 TLS_RSA_WITH_AES_256_CCM_8 0xC0,0x9C TLS_RSA_WITH_AES_128_CCM 0xC0,0xA0 TLS_RSA_WITH_AES_128_CCM_8 0xC0,0x87 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x86 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x8B TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x8A TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x7D TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x7C TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x7B TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x7A TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x5D TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x5C TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x61 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x60 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x53 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x52 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x51 TLS_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x50 TLS_RSA_WITH_ARIA_128_GCM_SHA256 If you're also looking to minimise the impact that private key theft will have, the list gets shorter still:

0xC0,0x2C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 0xC0,0xAD TLS_ECDHE_ECDSA_WITH_AES_256_CCM 0xC0,0xAC TLS_ECDHE_ECDSA_WITH_AES_128_CCM 0xC0,0xAF TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 0xC0,0xAE TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 0xC0,0x9F TLS_DHE_RSA_WITH_AES_256_CCM 0xC0,0xA3 TLS_DHE_RSA_WITH_AES_256_CCM_8 0xC0,0x9E TLS_DHE_RSA_WITH_AES_128_CCM 0xC0,0xA2 TLS_DHE_RSA_WITH_AES_128_CCM_8 0xC0,0x87 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x86 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x8B TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x8A TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x7D TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 0xC0,0x7C TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 0xC0,0x5D TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x5C TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x61 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x60 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 0xC0,0x53 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 0xC0,0x52 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 There is a further complication here: ARIA and Camellia GCM suites aren't supported by OpenSSL or NSS as yet, and may well never be. The CCM suites are only supported in very recent versions of OpenSSL (trunk only, I think) and not at all in NSS. So your list is now:

0xC0,0x2C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 However, AES-256 is discriminated against by Google because of its susceptibility to side-channel timing attacks. So if we drop that, we end up with:

0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 That's a pretty short list, and you're going to end up with a lot of people being unable to connect to your website if you do that. Furthermore, all three cipher suites are cryptographically broken, although they are considered secure because there is no practical attack against them.

Should you prioritise GCM suites over non-GCM suites, regardless of anything else? Absolutely (with the exception of ChaCha20/Poly1305 when the time comes). Should you drop CBC support? No, because a lot of people will be unable to connect to your website. Should you support 3DES? Probably not, unless you really have to. What about the others? Well, if it's still considered secure, why not - but remember that TLS 1.0 is a bit horrible, and anything CBC-over-TLS 1.0 is likely to cause you problems at some point down the line. PCI-DSS 3.1 will hopefully clear a lot of this mess up by forcing people to catch up with browser technology.

There is one simple question and answer, however: Should SSLLabs refuse to give an A+ to sites which don't prioritise GCM, CCM and ChaCha20/Poly1305 suites over all others? Yes.

To follow up on this, with OpenSSL, Google's recommendations for TLS 1.1 and later approximate to the following cipher suite:

ECDHE-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-CHACHA20-POLY1305-SHA256:DHE-RSA-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CAMELLIA128-GCM-SHA256:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CAMELLIA128-GCM-SHA256:ECDHE-RSA-ARIA128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-CAMELLIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CAMELLIA256-GCM-SHA384:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CAMELLIA256-GCM-SHA384:ECDHE-RSA-ARIA256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CAMELLIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM:ECDHE-ECDSA-AES128-CCM8:DHE-RSA-AES128-CCM8:ECDHE-ECDSA-AES256-CCM8:DHE-RSA-AES256-CCM8:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-ECDSA-ARIA256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-RSA-ARIA256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-ARIA256-SHA384:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-ECDSA-ARIA128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:ECDHE-RSA-ARIA128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-ARIA128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-SEED-SHA:AES128-GCM-SHA256:CAMELLIA128-GCM-SHA256:ARIA128-GCM-SHA256:AES256-GCM-SHA384:CAMELLIA256-GCM-SHA384:ARIA256-GCM-SHA384:AES128-CCM:AES256-CCM:AES128-CCM8:AES256-CCM8:AES256-SHA256:CAMELLIA256-SHA256:ARIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:AES128-SHA256:CAMELLIA128-SHA256:ARIA128-SHA256:AES128-SHA:CAMELLIA128-SHA:SEED-SHA:IDEA-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

the reason that cipher suite is considered obsolete by chrome was explained by google's adam langley here:

unfortunately, community.qualys.com and a lot of other sites still don't support any AEAD cipher suites.