[PATCH] slaying the BEAST (TLS 1.0 exploiting)

[Srebrenko Šehić]

On Sat, Oct 1, 2011 at 11:50 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

Hi,

> The patch won't help to stop BEAST (CVE-2011-3389), you need fix
> on *client* side to stop it.  More details about the attack
> may be found here:

To quote the Cisco article:

"Another thing to highlight is that OpenSSL implemented a feature
where they send an “empty TLS record” immediately before they send a
message. This empty TLS record causes a change in the CBC state where
people consider it to give the message “a new IV” that the attacker
can’t predict.  This feature in OpenSSL is disabled with the
“SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS” option and it’s also included in
the “SSL_OP_ALL” option.  In OpenSSL versions 0.9.6d and later, the
protocol-level mitigation is enabled by default, thus making it not
vulnerable to the BEAST attack."

> The only server-side workaround I'm currently aware of is using
> non-CBC ciphers, i.e.
>
>    ssl_ciphers RC4-SHA;

Agree. RC4 is the only generally available stream cipher supported by
most browser. However, that too might break some browsers as the
choice of ciphers gets pretty limited.

> For OpenSSL's "insert empty fragments" workaround on a server
> side, situation hasn't changed much since 2003: there is problem,
> there are no known attacks, and workaround causes major
> interoperability problems.

True. To my best knowledge though, only IE6.0 and lower are affected
which should not be that many. All moderns browsers should work just
fine with this workaround.

> (Probably working on better workaround in OpenSSL would be a good
> idea. It looks like Chrome's one-byte one causes much less
> problems.)

Anything requiring patches to be applied to OpenSSL takes a lot of
time. It's probably faster to update the browsers.

I still think the patch is valid enough, but maybe just default to
disabled (like it is now), but give people the choice?

Thanks,
Srebrenko