The SSL protocol, as used in certain configurations in Microsoft Windows
and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and
other products, encrypts data by using CBC mode with chained initialization
vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP
headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session,
in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API,
(2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a
“BEAST” attack.
Notes
Author |
Note |
mdeslaur |
in natty+, NetX and the plugin moved to the icedtea-web package |
jdstrand |
this is not a lighttpd issue, however dsa-2368 disabled CBC ciphers by default. Ignoring as this is a configuration issue. |
sbeattie |
openssl contains a countermeasure since openssl 0.9.8d, though it can be disabled with the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option (which is included in SSL_OP_ALL). Need to search through openssl user that enable the option. |
tyhicks |
All versions of gnutls in supported releases have TLS 1.1 and 1.2 support. TLS 1.1 and 1.2 are not affected by this attack. Upstream advised applications to use 1.1 and 1.2 in GNUTLS-SA-2011-1. Additionally, DTLS 1.0 can be used or RC4 can be used with TLS 1.0 if TLS 1.1 or 1.2 are not viable options. |
jdstrand |
arcticdog blog points out that users of SSL_OP_ALL should be updated to use ‘SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS’ to not be vulnerable to this attack |
mdeslaur |
removing SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS will break compatibility with certain SSL implementations, which is why it’s included in SSL_OP_ALL in the first place. Since the BEAST attack is only practical in web browsers where you can run arbitrary code, and current web browsers are already fixed, modifying other software in the archive to enable the work around will break compatibility with no added security benefit. |