On Sat, Oct 1, 2011 at 11:50 AM, Maxim Dounin <mdounin@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
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
