Good Morning Brian from what Im seeing this is a Redhat Enterprise 4,5,6 bug which effects any of the secure protocols such as sftp, scp and ssl and you would need to implement the RH patch dsiable TLS 1.0 and implement either TLS 1.1 or TLS 1.2 protocols in its place disable applets disable WebSockets disable Cipher Block Chaining (CBC) ciphers make sure 1/(n-1) split is being implemented replace your JSSE with a JSSE that supports jsse.enableCBCProtection
this update from tomas tells the story "A mitigation for this flaw was implemented in the Network Security Services (NSS) library. It uses 1/(n-1) record splitting as mentioned in comment #19. This mitigation was added in NSS version 3.13 (which is used in Firefox 9 and later) and is enabled by default upstream. Environment variable NSS_SSL_CBC_RANDOM_IV can be used to disable the mitigation when it causes failures to connect to servers that are intolerant to such record splitting (see comment #23). Setting the environment variable value to 0 disables the mitigation." use FF9 as your corporate browser https://bugzilla.redhat.com/show_bug.cgi?id=737506does anyone from Redhat have anything useful to say on this matter? Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te deer mandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Fri, 14 Sep 2012 22:12:30 -0500 > Subject: Is there a REAL solution to the "BEAST attack" (CVE-2011-3389) for > Tomcat 7.x > From: brianbr...@gmail.com > To: users@tomcat.apache.org > > Hi, > > Is there a REAL solution to the "BEAST attack" (CVE-2011-3389) for Tomcat > 7.x? > For more info about this attack: > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389 > > My toughts and questions, as far as I have investigated this issue: > > - Disabling the TLS1.0 protocol would be too restrictive, because there are > still browser versions in use that don't support TLS1.1 or TLS1.2. > - Should we restrict the ciphers in use? If so, which ones should we offer > for Tomcat 7.X over JVM1.6 and using a GeoCerts certificate (which means > JSSE instead of OpenSSL)? > - Will upgrading to the latest JVM (as of today, Sept 14th 2012) solve this > issue? > > Thanks in advace.
