[stunnel-users] EXTERNAL: Re: stunnel server configuration requirement to handle CBC protection
Janusz Dziemidowicz
rraptorr at nails.eu.org
Tue Nov 5 22:25:40 CET 2013
2013/11/5 Bucci, David G <david.g.bucci at 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).
--
Janusz Dziemidowicz
More information about the stunnel-users
mailing list