18

I'm looking at turning on site-wide SSL for a website I manage, and I'm wondering what the best practices for SSL configuration. I'm not too worried about compatibility with old browsers and more obscure mobile devices, so I'd like to cut down the supported cipher suite list.

The main issues I'm trying to avoid are CRIME and BEAST. The first one is easily mitigated by disabling compression, but the second one isn't quite as clear to me. The way I understand it, BEAST is an attack against CBC mode rather than a particular cipher, but it's generally been targeted against AES. As such, would AES-GCM be a good choice of cipher to use for SSL?

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • BEAST only applies to old versions of TLS. TLS 1.2 is never vulnerable to it, even when using CBC. But older versions of TLS don't support AES-GCM. – CodesInChaos Jan 24 '13 at 13:40
  • Interesting. I'm still interested in GCM though, since it's unusual to see on regular HTTPS sites. – Polynomial Jan 24 '13 at 13:42

2 Answers2

16

GCM is recommended; it is even approved by NIST. However, AEAD ciphers are supported in TLS only since TLS 1.2; see section 6.2.3.3, which is new, when compared to TLS 1.1. The actual GCM-able cipher suites are defined in RFC 5288. Note that TLS 1.2 (and, for that matter, TLS 1.1 too) is immune to BEAST-like attacks when using CBC.

Therefore you will have a hard time finding a Web browser which supports GCM right now (I write these lines in January 2013; hopefully, TLS 1.2+GCM support will become widespread at some point in time). It is still fine to enable it, and if the client supports it, so much the better; GCM will be most lightweight on recent x86 processors with the AES-NI opcodes (these opcodes have been designed specially for GCM, in particular PCLMULQDQ which implements multiplications in GF(2)[X]). Not that the CPU cost of traditional TLS cipher suites is that high, but it is intellectually pleasing to know that each server core could support 5 Gbit/s bandwidth.

But if you want existing browsers to actually, say, browse your server, then you will need to allow for more "primitive" cipher suites as well, if only as a fallback.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • So the best option is to enable AES-GCM and AES-CBC cipher suites on TLS 1.2, and RC4 suites on TLS 1.1? I don't plan on supporting any of the pre-TLS protocols. – Polynomial Jan 24 '13 at 14:19
  • 1
    @Polynomial: make it RC4 on TLS 1.0, AES-CBC on TLS 1.1, AES-GCM and AES-CBC on TLS 1.2. TLS 1.1 is immune to BEAST (it has per-record random IV). Also, I am not sure IE 7 on WinXP would support AES cipher suites; you might want to keep a 3DES cipher suite "just in case" (unless you are ready to ruefully reject old browsers). – Thomas Pornin Jan 24 '13 at 14:42
  • 1
    That sounds like a reasonable list. IE7 is almost 7 years old now, so I'd probably avoid 3DES. There's no reason for an end-user to be on IE7 these days, and I'm not too concerned about anyone who still is. – Polynomial Jan 24 '13 at 14:47
  • 1
    Hey, up to two weeks ago, I had XP+IE7 at work ! (But then they upgraded my desktop to IE8) – Thomas Pornin Jan 24 '13 at 14:49
  • I guess. I just don't like the idea that someone might do a downgrade through a MitM attack. – Polynomial Jan 24 '13 at 14:51
  • 1
    Normally, SSL/TLS is protected from downgrade attacks, since the `Finished` messages are hashes computed over all the previous handshake messages -- including the list of client-supported cipher suites. To do a downgrade attack, you have to downgrade to a cipher suite which you are able to break _immediately_ -- and the security issue is then supporting such an utterly weak cipher suite, not really the downgrade by itself. – Thomas Pornin Jan 24 '13 at 15:02
  • NIST's reputation and trustworthiness was demonstrated by its actions: http://blog.cryptographyengineering.com/2015/01/hopefully-last-post-ill-ever-write-on.html – dhchdhd Feb 13 '16 at 03:23
2

I realize the post is from 2013, but I happened upon this post when researching a patch for the latest openSSL vulnerability announced 3 May 2016 (Info - https://www.openssl.org/news/secadv/20160503.txt). The recommended patch is TLS1.2+AES-GCM cipher suite.

The latest browser on the latest OS should have support for AES-GCM at this point. If you'd still like to confirm this, this tool(https://cc.dcsec.uni-hannover.de/) will provide info on the SSL cipher suites supported by your browser.

ice.nicer
  • 121
  • 2