[stunnel-users] EXTERNAL: Re: stunnel server configuration requirement to handle CBC protection

Tue Nov 5 20:58:37 CET 2013

2013/11/5 Bucci, David G <david.g.bucci at 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-beast-attack-on-tls 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-broken-now-what
[2] https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat
[3] https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks
[4] https://community.qualys.com/blogs/securitylabs/2013/09/17/updated-ssltls-deployment-best-practices-deprecate-rc4
[5] http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01

-- 
Janusz Dziemidowicz