Knowledge Center Search

On September 23rd, 2011, a research paper was published at a security conference regarding an attack on the SSLv3/TLS 1.0 protocol. Up until recently this attack was only theoretical. 

MITRE CVE-2011-3389 describes the issue as follows:

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

For this attack to be carried out there are many requirements that need to fall into place. The attack in nature is difficult to exploit due to these requirements. For example, the attacker will need to be able to intercept all client network traffic as well as predict which HTTPS site the user will go to in the future. 

The following article describes the requirements for this attack to take place:

http://luxsci.com/blog/is-ssltls-really-broken-by-the-beast-attack-what-is-the-real-story-what-should-i-do.html 

More information on the attack:

http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

Note: Juniper is supplying these URLs for reference only. We do not guarantee nor have directly verified the validity of statements made by third parties.

MITRE CVE:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389

 

Juniper Networks is well aware of the reported issue and is investigating backward-compatible alternatives that will help mitigate the issue. Refer to the following table for information that has been provided by several major web browser vendors:

Microsoft Internet Explorer	http://blogs.technet.com/b/srd/archive/2011/09/26/is-ssl-broken-more-about-security-advisory-2588513.aspx
Google Chrome	https://src.chromium.org/viewvc/chrome?view=rev&revision=90643
Firefox	http://blog.mozilla.com/security/2011/09/27/attack-against-tls-protected-communications/
Apple Safari	N/A

Current known mitigations:

Client side:

The following article explains the possible client side mitigations:

luxsci.com/blog/is-ssltls-really-broken-by-the-beast-attack-what-is-the-real-story-what-should-i-do.html

Note: Juniper is supplying these URLs for reference only. We do not guarantee nor have directly verified the validity of statements made by third parties.

Server side:

By switching to RC4 based encryption, the issue can be completely avoided. This is because the vulnerability exists only with encryption methods that use CBC (Cipher-Block Chaining). RC4 is a stream based cipher; so it does not have this issue.

Note: RC4 is cryptographically less secure than AES or 3DES.

Juniper Secure Access (SA) / Infranet Controller (IC):

To enable only RC4:

Go to System > Configuration > Security > Allowed Encryption Strength > Custom SSL Cipher Selection and select only RC4 (under Medium).

ScreenOS:

In ScreenOS 6.3.0 Software Documentation for SSG, ISG, and NetScreen Series:

http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_all.pdf


Chapter 10: Administration

Secure Sockets Layer

The ScreenOS implementation of SSL provides the following capabilities, compatibilities, and integration:

• SSL version 3 compatibility (not version 2)


• The following encryption algorithms for SSL:


• RC4-40 with 40-bit keys


• RC4 with 128-bit keys


• DES: Data Encryption Standard with 56-bit keys


• 3DES: Triple DES with 168-bit keys

To work around this issue, you must select RC4 encryption in the ScreenOS configuration; as described in the above documentation.

Junos OS:

OpenSSL, which currently is part of Junos, has a counter measure for a known IV issue with CBC ciphers, which, by default, is enabled. Refer to the Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures link for more information about these countermeasures.

In particular, OpenSSL versions 0.9.6d or later (found in Junos 11.1R1 or ater) implement a feature, in which an empty TLS record is sent immediately, before sending a message. This empty TLS record causes a change in the CBC state, as in it triggers the a new IV message, which the attacker cannot predict. In OpenSSL versions 0.9.6d or later, by default, this protocol-level mitigation is enabled; which makes the Junos OS invulnerable to the BEAST attack.