2013/11/5 Bucci, David G david.g.bucci@lmco.com:
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.
Well, RC4 being broken was covered quite broadly this year in various places. If you have such policy then it really should be reviewed at least yearly (if not often) based on current research. Following all current cryptography work is a must if you wish to provide serious security;)
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.
Not having a practical attack for RC4 is not an excuse. Theoretical work for BEAST was known for a number of years before BEAST was developed and you have no guarantee that somebody did not make it earlier. Just consider this: - BEAST is defeated both in theory and practice by using TLS1.1/1.2 - CRIME is defeated, again both in theory and practice by disabling compression - Lucky13 was fixed in OpenSSL code at least - you have a theoretical weakness in RC4 with no known workaround or fix The choice is yours. It also depends on your threat model. Are you just trying to make impossible to sniff your users passwords on a shared Wi-Fi or are you working for Google and trying to defeat NSA. Quite a few things depend on answer to this question.
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.
This is flawed. Making downgrade attack, forcing your target to use TLS 1.0 (and thus RC4) is trivial.
In any case, back to the root question - is it possible to config stunnel to pass the cipher limitations/preferences to OpenSSL?
This is basic configuration easily found in man page: https://www.stunnel.org/static/stunnel.html
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.
That will make absolute no difference for BEAST. It might make CRIME harder (but disabling compression is best bet if you prefer security over performance).