Martin,

You know what a turtle is?


p

On 15 Sep 2012, at 13:30, Martin Gainty <mgai...@hotmail.com> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to