Hello!

On Sun, Oct 02, 2011 at 03:31:08PM +0200, Srebrenko Šehić wrote:

> 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 quote is correct, but as you probably noticed it doesn't say
anywhere that this workaround should be used on server to prevent
BEAST. It should be used on sending side, i.e. client in case of
BEAST.

> > 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.

This was just example. If you want to use RC4 in real life,
something like this should be used:

ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

It will prefer RC4 ciphers, though allow others if RC4 is not
available.

> > 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.

IE6 is still used by more than 2% of users over the world.

> > (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?

It may make sense, but right now it's at least misleading: people
may think they are safe from BEAST with this workaround enabled on
server, while they are not.

Maxim Dounin

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel