Hi Chris, thanks for sharing your opinion.
Just my last comment here to close this thread.
BSAFE is anyways EOL now (or will be soon). We are already working on a 
replacement. Currently we are using the latest and greatest version of BSAFE 
with extended support.
Once again, thank you all for the great support.
I have another query (different topic) coming shortly...:-)

Sent from my iPhone

> On Oct 12, 2017, at 7:59 PM, Christopher Schultz 
> <ch...@christopherschultz.net> wrote:
> Hash: SHA256
> Harish,
>> On 10/12/17 10:55 AM, Harish Krishnan wrote:
>> Thank you all for the help and responses. We figured out what the
>> problem was. What I did was correct in terms of the attribute
>> setting, the tomcat version used and the JRE version used. However,
>> I did not realize our JRE is running in FIPs mode using RSA BSAFE
>> as the crypto provider.
> FIPS strikes again!
> In this case, it's not really FIPS's fault, it's RSA's BSAFE. Anyone
> using RSA's BSAFE these days ought to lose their job. Plow that thing
> under with salt and use a trusted crypto provider (lol, Oracle, I guess)
> .
>> When I tested and ran under standard JRE, then the server cipher 
>> suite order was preferred.
> You are probably using an ancient version of BSAFE. Your random
> numbers are probably all ones. Seriously, you need to dump BSAFE.
>> Now I will have to look into what RSA library is doing here.
> Leaking like a sieve, probably.
>> Probably they are setting that Java API too which could be 
>> overwriting our setting in tomcat.
> If that crypto provider is in use, then it'll likely affect the whole
> JVM. It just occurred to me that Tomcat doesn't have a setting for the
> crypto provider to use for TLS itself... only for the various
> "stores", etc. We probably ought to add that, and then you could
> choose "JSSE" as your provider and avoid BSAFE.
> - -chris
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> pFjanhAAkTNcGk5/X6b9aK2gYcSDdTjkE879XA77KGYwWDF2L01jtSdF7ejnCcuN
> 4lfivY/V5TaiKv0EZrU1YVC2psBZVK5CjfsCIfUZe5gOmqRRtxm8vRARULOY31oQ
> tm4Hf3PHVXuKa/ZBQutLFOolJo7IhaYP3CtBqE+i7OWSlyy0dsqdqO40z9+vzt2n
> DBiMRXl0Y2HGCeRsm0owdsFFDqA/j0xcCTBjgckgR6TcnRPc926FZVmr+q53DEQ1
> rYVo3Kfum7AnLP3y4rVT0SsxavjI48aXqCLKcM9RzRJ//D+p9teOeiHiUtu4CzHY
> aQmkV22N6LC3M5uBwNNU1xXr62SNiarqY7euurPhPcOkbQSi4ckfknh48JzenQ41
> Ws7XvuLGOmTcLOv+rsKYjBd5s6IxuBH/+k5MfttPQaZ8mHAieMjEnVszmjZon2rE
> Mqqcd+C5Z0q2/X9wUAwNAD3muQTzx2A8C3uucJHVygvwNy76UCUCoyLakQ98/8WL
> 3SKN2l3EddObdi4OUrfga80ZTLf0AnBoflmKz+2UAbP3Xit++XHBs5dBgvN51Tji
> d6IdBRJpSq/njZmnSGQYJ/4o07v31YgLjh+xZTS+8wxm5H3C4V6/IuWlsnYPZWi5
> =KUgn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

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

Reply via email to