5 ms·
Hardening your Web Server's SSL Ciphers
- hn-miw-i 14y agoDon't know if I agree re RC4; BEAST is an issue with CBC, not AES. AES-GCM should be ok, if not superior to the ancient RC4.
- hynek 14y agoRC4 has no known practicably exploitable weaknesses and is well supported, insofar the “ancient” is actually working in its favor. That said, if you know as much as you do, you don’t need that article and can fine tune yourself. It’s for people who want a compatible and secure SSL setup – which it is.
- thirsteh 14y agoThe statement that RC4 has no weaknesses is not true. It has well-known biases: http://en.wikipedia.org/wiki/RC4#Security http://en.wikipedia.org/wiki/RC4#Security It is just better than CBC (as implemented), being a stream cipher, and thus using RC4 is the best solution right now. It is still important to get as much as possible up to TLS 1.2 and using AES-GCM or other AEAD modes as soon as possible. Edit: Clarified that RC4 is better than CBC as implemented, not CBC implemented with constant-time verification, i.e. RC4 will not be preferable to AES-CBC in the fixed version of OpenSSL, at least against the Lucky Thirteen attack.
- hynek 14y agoAbsolutely. But since we still have to support SSLv3 from 1996, I wouldn’t hold my breath. :(
- thirsteh 14y agoYeah. The outlook is not that great, and RC4 will definitely be better than CBC for those legacy systems in light of this discovery (http://www.isg.rhul.ac.uk/tls/ http://www.isg.rhul.ac.uk/tls/). At least the browsers are actively working on supporting the latest TLS and modes.
- hynek 14y agoYes, the discovery of Lucky13 and the following helplessness by many not-really-ops-but-doing-it-anyway people were the motivation to write that article in the first place. To get a minimal baseline security out there. Those who know better, will do better. There’s enough additional links to get hooked up. Can’t do more. :)
- tptacek 14y ago"Lucky 13" isn't exactly an ops crisis. You probably don't need to stay up late patching this one, unless you're using DTLS.
- hynek 14y agoOh certainly not a crisis – especially since it didn't bring new vectors to the table. I just saw many “what now!?”s in my timelines and figured I better give them a solid good-enough solution that just works before they do something stupid.
- huxley 14y agoDo we really? What browsers don't support at least TLS 1.0? Or is it other user agents?
- hynek 14y agoIt very much depends on your target audience. We’re in the web hosting business and whenever we try to be a bit more progressive, people start yelling at us that their IE 4-using customers in rural Mongolia can’t SSL-surf their shop. When it comes to mail, IIRC some business phones were behind too. OTOH iOS 6 support TLS 1.2, so if you’re just building a REST API for your own apps, you can go wild.
- tptacek 14y agoRC4 isn't "better" than CBC (it's much worse). But people hold their noses and use it because browser upgrade cycles haven't shaken off a bug that happens to affect CBC mode.
- thirsteh 14y agoYou are extracting something I didn't say, or at least didn't mean to imply. RC4 is better than TLS-CBC as it is implemented by virtually all libraries. A constant-time implementation is obviously preferable, but considering the mess this makes of client libs I doubt many will adopt it. RC4 will be better for those until TLS 1.2 and e.g. AES-GCM are supported. As an example, see Adam Langley's comments on not fixing (i.e. making constant-time) CBC in Go: https://groups.google.com/d/msg/golang-nuts/HF5O5vAKRcQ/3cYWryRyZboJ https://groups.google.com/d/msg/golang-nuts/HF5O5vAKRcQ/3cYW... Also, blaming browsers when we've known about timing attacks against this verification for years, and OpenSSL is patching it now, is probably a bit of a stretch.
- tptacek 14y agoYou're commenting at a greater level of detail than I am. I'm only making the AES-CBC > RC4 case because it would be awfully dumb of someone to design a new cryptosystem with RC4, even if AES-CBC was the only alternative. The CBC timing channel 'agl is talking about is specific to TLS's idiosyncratic mac-then-encrypt implementation. Don't ever use mac-then-encrypt. Encrypt first, then MAC. I'm blaming browsers for (a) not implementing CTR mode (AE or otherwise) and (b) being vulnerable to the chained CBC IV vulnerability. I'm not blaming browsers for the timing attack on AES-CBC.
- thirsteh 14y agoAh, yes. I agree.
- tptacek 14y agoAES-GCM is vastly superior to RC4 but not widely supported.
- dfc 14y agoTake a look at applebaum's duraconf. It has configs for many ssl/tls services: https://github.com/ioerror/duraconf https://github.com/ioerror/duraconf
- hynek 14y agoThanks, I’ve added it to the article.
- nachteilig 14y agoAnyone used his config for nginx? How does his cipher list affect speed?
- dochtman 14y agoI think this CipherSuite is actually better than what you have (and Qualys seems to think so, too): SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH Also, I couldn't get your disabling of SSL compression to work (on Gentoo Linux), either by pasting the export line into /etc/conf.d/apache2 (at the end) or /etc/init.d/apache2 (at the top).
- hynek 14y agoYes, but some of the ciphers aren’t supported in widely used OpenSSL versions (like 0.9.8). I wanted to give people a configuration that works everywhere and is reasonable secure. If they want more, there’s a link list at the end. Let’s not make perfect the enemy of the good. Edit I’ve added an advanced section with a link to here so you get your credit. :)
- timdoug 14y agoTo be fair, that line does work everywhere; the unrecognized ciphers are just ignored. In fact, on my Debian VPS with OpenSSL 0.9.8 it results in the exact same list of ciphers as the Apache one given in the post ("openssl ciphers" on the command line is very useful). May as well add the newer ones to get the support if you upgrade your SSL library without having to change your Apache/nginx/etc. conf.
- jgrahamc 14y agoThat, coincidentally, is the configuration that we (CloudFlare) are using for all our SSL sites: http://blog.cloudflare.com/new-ssl-vulnerabilities-cloudflare-users-prot http://blog.cloudflare.com/new-ssl-vulnerabilities-cloudflar... One of the things we try to do for our customers is worry about this sort of thing so they don't have to.
- CrLf 14y agoFor openssl 0.9.8, where "ECDHE-RSA-AES128-SHA256" and "AES128-GCM-SHA256" aren't supported, that cipher suite actually places RC4 40bit as the preferred cipher ("openssl ciphers -v").
- Erwin 14y agoHow does SSL compression work together with Apache's ordinary zlib support? Is it redundant when you're already deflating text/html pages? Looking at a page fetched from my server, Apache respondents with Content-Encoding: gzip.
- acdha 14y agoFocusing on the CRIME attack people are trying to prevent, TLS compression works for the entire session and will thus include the HTTP headers which are out of band from HTTP transfer encoding. That's how CRIME works: if an attacker can use something like JavaScript to make a request in your browser with some text which they control and can observe the packet sizes, they can measure whether the entire message compressed more than expected, indicating that some bytes are shared between the browser-generated headers and their injected contents. Repeat enough times and you can recover cookies byte by byte. See http://www.imperialviolet.org/2012/09/21/crime.html http://www.imperialviolet.org/2012/09/21/crime.html for the full details. The good news is that Content-Encoding avoids the attack; the bad news is that it means we're missing the opportunity to avoid transmitting a significant chunk of repetitive text.
- deleted 14y ago[deleted]
- boonedocks 14y agoAnyone else having trouble getting "export OPENSSL_NO_DEFAULT_ZLIB=1" to work on Apache 2.2.22, CentOS 5.9? I have tried it in /etc/sysconfig/httpd and /etc/init.d/httpd (in start) and SSL tools still report that compression is on.
- hynek 14y agoHm, I'm just on my phone now and going to bed but here's link from RH's bugzilla going into it, maybe it's of any help to you: https://bugzilla.redhat.com/show_bug.cgi?id=857051#c5 https://bugzilla.redhat.com/show_bug.cgi?id=857051#c5 Can't say any more than that it works for us – we compile Apache ourself though for various reasons. But according to the link above it should work.