Bugzilla – Bug 719047
VUL-1: Adaptive chosen plaintext attack against SSL (BEAST Attack)
Last modified: 2020-02-19 10:24:22 UTC
Hackers break SSL encryption used by millions of sites. Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that's passing between a webserver and an end-user browser. The vulnerability resides in versions 1.0 and earlier of TLS, or transport layer security, the successor to the secure sockets layer technology that serves as the internet's foundation of trust. Although versions 1.1 and 1.2 of TLS aren't susceptible, they remain almost entirely unsupported in browsers and websites alike, making encrypted transactions on PayPal, GMail, and just about every other website vulnerable to eavesdropping by hackers who are able to control the connection between the end user and the website he's visiting. the full text: http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
Well, interesting but what could we do about it?
(In reply to comment #1) > Well, interesting but what could we do about it? there is still no official response to this attack. but it clearly exist. version upgrading can avoid the attack,but issuses of application compatibility will occur. currently, we just mark this attack and make further analysis.
Some references: Publication about the problem: http://eprint.iacr.org/2006/136 Countermeasures in openssl: http://www.openssl.org/~bodo/tls-cbc.txt http://cvs.openssl.org/chngview?cn=6452
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is in SSL_OP_ALL though so disabled in many openssl using programs.
CVE-2004-2770 The SSL protocol 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. Reference: MISC: http://www.insecure.cl/Beast-SSL.rar Reference: MISC: http://www.imperialviolet.org/2011/09/23/chromeandbeast.html Reference: MISC: http://isc.sans.edu/diary/SSL+TLS+part+3+/11635 Reference: MISC: http://eprint.iacr.org/2004/111 Reference: MISC: http://ekoparty.org/2011/juliano-rizzo.php
CVE-2004-2770 shall not be used. CVE-2011-3389 should be used instead.
respective mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=665814
tag
Some more references Report about the openssl solution causing trouble with (broken) oracle servers: https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c30 IE6 not able to connect to openssl server: https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c50 Alternative solution which sends one byte instead of an empty fragment: https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59 This issue is only known to hit browsers so far AFAICS as an attacker needs to precisely control the data sent. So the issue is not critical for openssl. It would be desirable to have the 1/n-1 split implemented in openssl too though.
Update released for: mozilla-nss, mozilla-nss-32bit, mozilla-nss-debuginfo, mozilla-nss-devel, mozilla-nss-tools Products: SLE-SERVER 10-SP3-TERADATA (x86_64)
the new openssl release also covers this issue i think, tracked in bug 739719 only gnutls missing then...
Patch suggestion to enable 1/n-1 splitting in openssl: http://rt.openssl.org/Ticket/Display.html?id=2635&user=guest&pass=guest
Does anyone know what's the current status for this issue?
SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would enable the protection measure, but clients or servers might not work with that, see #c10. We even had to add code for "curl" to allow the BEAST attack again. bnc#755908 As soon was we get TLS 1.1 or 1.2 this issue should be fixed more or less automatic.
I checked the CVE description: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389 The affected applications are browsers but no openssl in the list. This issue is seem only the matter of application usages. Should I merge the experimental patch which Ludwig pointed[1]? Or just close it as "won't fix"? [1] http://rt.openssl.org/Ticket/Display.html?id=2635&user=guest&pass=guest
the problem was mitigated on the client side.