I understand the TLS cipher suites using CBC mode are susceptible to timing attacks. From that understanding it seems that the cipher suites using GCM (CTR-based) are safe to use considering they don't need padding.

However, in Java, SunJSSE provider by default enables many cipher suites that are using CBC. And whether those cipher suites will be used or not are determined by the client preference.

While using Chrome and FireFox latest versions, I noticed the cipher suite used is AES_128_GCM.

Now, is it advisable to disable all the CBC related cipher suites in the server to ensure only GCM is used regardless of the client preferences? Is there any limitation with this approach of using only GCM related cipher suites?

  • 3
    $\begingroup$ I believe Qualys can provide you with a compatibility report when enabling various suites. $\endgroup$
    – forest
    Oct 19 '18 at 7:10
  • 1
    $\begingroup$ ... and if your server is internal-network only, you can still use the bear's TestSSLServer $\endgroup$
    – SEJPM
    Oct 19 '18 at 8:48
  • 5
    $\begingroup$ Further it would appear that using only GCM will block out pre-4.3 android, pre-7 java, pre-11 internet explorer, pre-1.0 openssl as well as pre-7 safari on OS X. Now you have to decide whether your clients / customers will use any of these browsers. $\endgroup$
    – SEJPM
    Oct 19 '18 at 8:51
  • 3
    $\begingroup$ Adding on to @SEJPM, GCM was introduced in TLSv1.2, so any other clients that only support older versions will be blocked out as well. $\endgroup$ Oct 19 '18 at 18:48
  • $\begingroup$ (@SEJPM) OpenSSL 1.0.1 up is okay, but not 1.0.0 (or lower). Free Java7 had TLS1.2 but not GCM; paid 7u191 as of a few months ago reportedly adds it. All j8 up are okay -- or all j5 up if you use BCTLS instead of SunJSSE. $\endgroup$ Oct 20 '18 at 3:43

Based on the useful comments above, some of the resources I found to provide an insight into the matter is as follows:

  1. TLS Support tells us which browser versions support which TLS versions. Since (as puzzlepalace mentioned) GCM was introduced in TLSv1.2, we get an idea as to what browser versions we'll miss out by supporting only GCM
  2. Qualys (as forest mentioned) shows some of the best SSL configured website and the cipher suites used. This also shows the cipher suites used by your browser. The best practices for TLS deployment and the recommended list of cipher suites are listed here. Finally, this table lists which browser versions support what.

In summary, all major browsers support TLS 1.2 since Oct, 2013 and therefore GCM.

Forward secrecy (ECDHE) is available from even before.

  • $\begingroup$ TLS1.2 does not require and does not necessarily imply GCM, although most implementations added them together. In particular as I commented on the Q, Java7 SunJSSE implemented 1.2 without AEAD until long after the end of free support. $\endgroup$ Oct 12 at 0:15

In moz://a SSL Configuration Generator both "Modern" and "Intermediate" configurations contain ciphers suites which simultaneously assure the confidentiality and authenticity of data (AEAD) as GCM does, but not only GCM does. See Poly1305 and Encrypt-then-MAC (EtM) for details. In "Modern" mode only TLS 1.3 is enabled, where the standard contains only AEAD cipher. Only the "Old" configuration contains CBC ciphers. In this point of view if you want to support modern and intermediate client you do not have to support CBC ciphers. If backward compatibility is a must and you have to provide CBC ciphers always user cryptographic libraries and server applications support Encrypt-then-MAC extension for TLS or at least prefer AEAD ciphers over not AEAD ones as the well-configured clients do it and NIST suggests it in SP 800-52.

As the author (of this website) I would suggest to check TLS setting by Scanigma as all the criteria mentioned are checked, explained and graded by it.

  • 2
    $\begingroup$ It appears that you are the author/owner of the linked website. Please disclose your affiliation with your websites and videos (in the answer) in order for your posts not to be considered spam. For more info please see How not to be a spammer. $\endgroup$
    – Ollie
    Oct 11 at 17:08
  • 3
    $\begingroup$ Thanks for the warning @ollie . It was thought that the username makes it clear for the readers, but the comment was also modified hopefully according to the needs. $\endgroup$
    – Scanigma
    Oct 11 at 17:26

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.