Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardening your Web Server's SSL Ciphers

hynek.me

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Hardening your Web Server's SSL Ciphers

#21

Post by tptacek »

hynek wrote: post #15
thirsteh wrote: post #8

Earlier quoted context omitted.

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.

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. :)

"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.

Re: Hardening your Web Server's SSL Ciphers

#22

Post by acdha »

Erwin wrote: post #18

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.

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.

Re: Hardening your Web Server's SSL Ciphers

#23

Post by ksdlck »

dochtman wrote: post #9

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).

Unless you're worried about lack of GCM (and I guess you're not, given the next suite spec), you might as well make that highest-preference suite ECDHE-RSA-AES128-GCM-SHA256.

Re: Hardening your Web Server's SSL Ciphers

#24

Post by thirsteh »

tptacek wrote: post #19
thirsteh wrote: post #16

Earlier quoted context omitted.

You 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…

You'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…

Ah, yes. I agree.

Re: Hardening your Web Server's SSL Ciphers

#26

Post by huxley »

hynek wrote: post #6
thirsteh wrote: post #5

Earlier quoted context omitted.

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 implemente…

Absolutely. But since we still have to support SSLv3 from 1996, I wouldn’t hold my breath. :(

Do we really? What browsers don't support at least TLS 1.0? Or is it other user agents?

Re: Hardening your Web Server's SSL Ciphers

#28

Post by hynek »

boonedocks wrote: post #25

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.

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.

Re: Hardening your Web Server's SSL Ciphers

#29

Post by hynek »

tptacek wrote: post #21
hynek wrote: post #15

Earlier quoted context omitted.

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. :)

"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.

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.

Re: Hardening your Web Server's SSL Ciphers

#30

Post by [deleted] »

ksdlck wrote: post #23
dochtman wrote: post #9

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).

Unless you're worried about lack of GCM (and I guess you're not, given the next suite spec), you might as well make that highest-preference suite ECDHE-RSA-AES128-GCM-SHA256.

[deleted]
Post reply on HN