Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

1 Answer

up vote 10 down vote accepted

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.

share|improve this answer
    
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
    
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
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
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.