Hmm. I had heard some of this but not gotten to studying it in better detail, thx. Unfortunately, our security posture is dictated to us, and deprecating CBC is active guidance, where I haven't seen any guidance yet on RC4 ... but that could change any day.
I do wonder, though, at the strength of that recommendation to revert to CBCs ... BEAST and CRIME and Lucky13 have actual, working attack software known to be in use, no? And I'm not dismissing it, but the attack vector seems more limiting for an RC4 vulnerability - millions of hits during the session using different keys + known string, all having to be run from within your browser/client context.
Maybe a better posture would be, prefer CBCs for TLS1.1/1.2, but if falling back to TLS1.0/SSL3.0, use RC4. No? I think some of my network devices have that flexibility - not sure about OpenSSL, if you can control based on protocol.
In any case, back to the root question - is it possible to config stunnel to pass the cipher limitations/preferences to OpenSSL?
p.s. I AM considering stuffing a few hundred bytes of meaningless, random headers into some of my apps' returns, however, as a quick fix. At least move the problem to the right on the probability graph.
-----Original Message----- From: Janusz Dziemidowicz [mailto:rraptorr@nails.eu.org] Sent: Tuesday, November 05, 2013 2:59 PM To: Bucci, David G Cc: Simner, John; stunnel-users@stunnel.org Subject: Re: EXTERNAL: Re: [stunnel-users] stunnel server configuration requirement to handle CBC protection
2013/11/5 Bucci, David G david.g.bucci@lmco.com:
Can I just ask - is there no way to simply exclude the vulnerable CBC-based ciphers during the stunnel startup, so that when the client connects, there will never be a successful negotiation to use one of them? That's how I fix it on our load balancers, set them to require e.g. RC4-SHA (actually, I have a preferred order, with TLS1.2 ciphers preferred, but fallback to RC4-SHA for clients that don't support TLS1.2, which is most - see https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-be... for more info).
This is not a good solution. Unfortunately, with the current state of software there are no good solutions [1]: - the real and proper solution is to use only TLS 1.1/1.2 and disable TLS 1.0 - but most implementations do not support TLS1.1/1.2 at all - another you have mentioned is preferring RC4... but RC4 was found to be quite broken; in fact RC4 is now considered probably more vulnerable than BEAST itself [2] - mitigating the threat on the client side by record splitting (either 0/n or 1/n-1) - but this can be done only on the client side due to the way BEAST works
For this reason Qualys, that you have referenced, now considers having RC4 a worse thing that being vulnerable to BEAST. BEAST is mitigated on the client (browser) side [3] so it is now generally advised to disable RC4 completely [4] [5].
On the other hand, please note how does BEAST attack work. It requires attacker to be able to send arbitrary data from the victim to the server. This is true in case of a browser (custom Java applet was used for this purpose in original BEAST attack). But this might not be true if TLS is used for traffic different than HTTP. Unfortunately it is unclear what kind of traffic is passed between the phone and client in this particular case. It is possible that this particular scenario is not vulnerable to BEAST attack at all. In such case preferring RC4 will just lower the security without fixing anything. Do remember to properly evaluate any potential vulnerabilities and if they apply to given case as blindly following any, otherwise correct, workarounds might cause more harm.
[1] https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-bro... [2] https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-... [3] https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-bea... [4] https://community.qualys.com/blogs/securitylabs/2013/09/17/updated-ssltls-de... [5] http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
-- Janusz Dziemidowicz