Bug#654764: Apache and BEAST
On Saturday 15 September 2012, Christoph Anton Mitterer wrote:
> I wondered about the status of the BEAST attack in Debian,
> especially:
>
> 1) Can I use any cipher suite and still be secure (e.g. use AES and
> disable RC4; the later which is often claimed to secure things...
> while there are however sources on the web claiming it would be
> even more vulnerable than AES)?
>
> 2) I know most browsers mitigate it already on their side,.. but I
> guess just by not selecting CBC ciphers if possible (???)... what
> however if I only offer such?
Browsers now have a workaround that splits/inserts TLS records that
cause the IV to be changed. So this works also with CBC ciphers. This
is basically the same what openssl does since before 0.9.6. Some
explanation is here:
http://my.opera.com/securitygroup/blog/2011/12/11/opera-11-60-and-new-
problems-with-some-secure-servers
> So question is,.. how can I force it on the server side, to be
> secure against BEAST.
Unless you forbid CBC ciphers, I don't think you can do anything on
the server. Not even detect if the browser has the workaround. But
forbidding the CBC ciphers gives up perfect forward secrecy and thus
lessens security for browsers that do have the workaround.
> which claim openssl fixed the problem already on a protocol level
> (even for TLS 1.0).
>
>
> So can we verify whether in Debian's openssl that
> SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is set?
The fix/workaround needs to be done by the browser. Only few browsers
use openssl. Non-browser HTTP-clients should not be vulnerable because
they tend to not give the attacker enough control (by not executing
java script).
So, as a summary, this is just another issue that needs to be
addressed by the browser. If a user uses an old browser that does not
have the fix, yet, the will have so many security issues that the
BEAST attack won't matter.
Reply to: