

Hardening your Web Server's SSL Ciphers - roguelynn
http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

======
dochtman
I 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
Yes, 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
To 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.

------
dfc
Take a look at applebaum's duraconf. It has configs for many ssl/tls services:

<https://github.com/ioerror/duraconf>

~~~
nachteilig
Anyone used his config for nginx? How does his cipher list affect speed?

------
hn-miw-i
Don'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
RC4 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
The statement that RC4 has no weaknesses is not true. It has well-known
biases: <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
Absolutely. But since we still have to support SSLv3 from 1996, I wouldn’t
hold my breath. :(

~~~
thirsteh
Yeah. 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/>). At least the browsers are actively working
on supporting the latest TLS and modes.

~~~
hynek
Yes, 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
"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
Oh 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.

------
boonedocks
Anyone 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
Hm, 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>

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.

------
Erwin
How 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
Focusing 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> 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.

