[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: