11

A company have made a vulnerability scan and give us a report that, recommends to use TLS 1.2 and enable only AEAD ciphers suite, but they aren't giving more information about what I need to achieve this.

I haven't found the list of this ciphers suites, that are compliant with this requirement. Also want to know if there is way to identify, with the name of the suit if a suite is compatible with AEAD.

kimo pryvt
  • 469
  • 4
  • 6
  • 12
  • [This Q/A](http://security.stackexchange.com/questions/76993/now-that-it-is-2015-what-ssl-tls-cipher-suites-should-be-used-in-a-high-securit) provides some very good answers. [SSLLabs's best practices document](https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices) is also very useful. – Luis Casillas Sep 16 '16 at 18:27
  • A newer, very useful resource: [Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/), where you just make some selections and it writes a config file for you. – Luis Casillas Mar 19 '18 at 23:30

2 Answers2

10

Don't do this. At least, don't do this on any system where you don't know for sure that it's not going to break things.

AEAD stands for "Authenticated Encryption with Additional Data" meaning there is a built-in message authentication code for integrity checking both the ciphertext and optionally additional authenticated (but unencrypted) data, and the only AEAD cipher suites in TLS are those using the AES-GCM and ChaCha20-Poly1305 algorithms, and they are indeed only supported in TLS 1.2. This means that if you have any clients trying to connect to this system that don't support either TLS 1.2, or even those that do support TLS 1.2 but not those specific cipher suites (and they're not mandatory...Only TLS_RSA_WITH_AES_128_CBC_SHA is mandatory, and it isn't an AEAD cipher suite) then those clients will not be able to connect at all.

It is true that these are the most secure options, and indeed the only options that will be supported for TLS v1.3, but for most systems today, this is not a realistic configuration. You do certainly want to enable TLS v1.2 and these cipher suites if you have an option to do so (configuring them is going to be specific to your system, so check your documentation) but as a rule, you should not require them unless you really know what you're doing and understand both your environment and the effects.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • It is also a performance problem. With Java clients for example GCM is much slower than CBC (despite improvements to enhance GCM for JCE) – eckes Mar 19 '18 at 19:11
  • 2
    This is still good advice, but as of now (March 2018), you are not going to break anyone's (99.9999% of peoples) access to your site by requiring AEAD. See Answer from ahvm – superphonic Mar 29 '18 at 09:24
  • @superphonic We're not anywhere close to that yet, unfortunately. As of the beginning of this year, more than 10% of the connections negotiated by CloudFlare were TLS 1.0. – Xander Mar 29 '18 at 13:47
  • @Xander I'd be interested in seeing those stats... – superphonic Mar 29 '18 at 14:12
  • @superphonic https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/ – Xander Mar 29 '18 at 14:14
  • @Xander That may be, but PCI compliance scans require TLS 1.0 to be disabled to pass. So if you do something that requires a PCI scan (accept credit cards on your website without using the hosted fields method, for example) then you are still required to disable TLS 1.0 regardless of any statistics. – ahwm Mar 29 '18 at 19:23
  • Just as some more information: https://support.cloudflare.com/hc/en-us/articles/205043158-PCI-3-1-and-TLS-1-2 – ahwm Mar 29 '18 at 19:27
  • @ahwm That will be true soon, but that's a separate issue. – Xander Mar 29 '18 at 19:28
  • @Xander But related. Because of the mass upgrade to TLS 1.2 by the payment industry, that requires ecommerce sites to upgrade, which requires browsers to upgrade. As a real-world example, thinkgeek.com is TLS 1.2 only. https://www.ssllabs.com/ssltest/analyze.html?d=thinkgeek.com As is GitHub https://www.ssllabs.com/ssltest/analyze.html?d=github.com – ahwm Mar 29 '18 at 19:39
  • https://blog.pcisecuritystandards.org/preparing-for-pci-dss-key-dates "Starting 1 February 2018 they are effective as **requirements**" – ahwm Mar 29 '18 at 19:42
  • @ahwm Two things. 1) That date is wrong, because that is a three year old post. It's 30 June 2018. 2) Requiring TLS 1.2 is an *entirely* different (and less restrictive) proposition to requiring AEAD only ciphersuites. – Xander May 03 '18 at 14:56
  • For completeness: there are also 1.2 AEAD suites using AES-CCM, and ARIA-GCM and Camellia-GCM, but they are not widely implemented; only the first is proposed to remain in 1.3 (along with AES-GCM and ChaCha-Poly). – dave_thompson_085 Jul 03 '18 at 06:39
2

The accepted answer is a couple of years old, now, and only a select number of browsers still do not support TLS 1.2 by default and they only account for roughly ~5% of all web traffic. IE on Win XP and IE < 11 on newer versions are the biggest culprits.

This link displays a matrix of browsers that support TLS 1.2.

Chrome has supported it since version 30 (the current stable version is 64, I believe).

Windows Server 2012 R2 still doesn't support the *RSA*GCM* suites (as I recently found out trying to enable them on our web servers) so Server 2016/Windows 10 and IIS 10 will be required to use the RSA-based AEAD ciphers.

PCI compliance now requires disabling TLS 1.0, and it's only a small user base that still requires the use of TLS 1.0. So as of 2018, it is perfectly acceptable to make these changes so long as your server OS supports them.

ahwm
  • 129
  • 3
  • 1
    This is still incorrect. Many older clients simply don't support an array of AEAD ciphersuites, and this would be a very dangerous change to make (even in mid-2018!) without proper testing to verify you aren't going to have significant client connectivity issues. – Xander May 03 '18 at 15:00
  • Another consideration is the support/compatibility with native app clients (Windows EXE, Android, iOS, etc.) that connect to API through HTTPS, not only web browsers. – Andrew T. May 14 '20 at 09:17