Thanks Colm!

Yeah, I already played with those workarounds like pre-registering BC at last 
slot via java.security or removing BC from the classpath and they all fix the 
issue. I wasn’t sure if BC is needed for the stuff we rely on which is just 
signature and basic PKI. The “addJceProviders” route is really not possible in 
our case because wss4j is used and managed by axis2 1.4/rampart 1.4 and those 
libraries provides no interface or way to interact with the WSSConfig and wss4j 
initialization to the service caller. Before posting on this list and made sure 
I explored this route. So really the 2 options are remove BC and pre-emptively 
register at higher slot…

Just curious though, is what you say about BS’s dependency for Kerberos support 
and other things still valid for latter JREs such as 7 & 8? It seems the native 
crypto support has improved lately. Also I am curious if the 1.6 and 2.x 
branches still force BC in slot 2 since most of the crypto APIs now let you 
specify a provider object that would carry the operation…

George


From: Colm O hEigeartaigh [mailto:[email protected]]
Sent: Monday, April 27, 2015 3:56 AM
To: [email protected]
Cc: [email protected]
Subject: Re: wss4j-1.5.12 & Bouncy Castle

Hi George,
The reason that BouncyCastle is inserted in position 2 in the provider list is 
covered in the JIRA you linked to. BouncyCastle is required for a few things in 
WSS4J, for example Kerberos decoding support in later versions. If you are 
using the basic algorithms then it may not be required. Simply try excluding 
the BouncyCastle jar from your project and see if it works? Failing this, you 
can set the "addJceProviders" property of WSSConfig to "false", which will turn 
off adding BouncyCastle. BTW WSS4J 1.5.x is no longer supported.
Colm.

On Sun, Apr 26, 2015 at 12:11 AM, George Stanchev 
<[email protected]<mailto:[email protected]>> wrote:
The relevant code is [2]. At [1] we can see that Colm has chimed in so maybe he 
can comment on this mess?


George

[1] https://issues.apache.org/jira/browse/WSS-99


[2]

//
                // Install the provider after the SUN provider (see WSS-99)
                // Otherwise fall back to the old behaviour of inserting
                // the provider in position 2. For AIX, install it after
                // the IBMJCE provider.
                //
                int ret = 0;
                for (int i = 0; i < provs.length; i++) {
                    if ("SUN".equals(provs[i].getName())
                        || "IBMJCE".equals(provs[i].getName())) {
                        ret =
                            java.security.Security.insertProviderAt(
                                (java.security.Provider) c.newInstance(), i + 2
                            );
                        break;
                    }
                }
                if (ret == 0) {
                    ret =
                    java.security.Security.insertProviderAt(
                        (java.security.Provider) c.newInstance(), 2
                    );
                }

-----Original Message-----
From: George Stanchev [mailto:[email protected]<mailto:[email protected]>]
Sent: Saturday, April 25, 2015 4:48 PM
To: [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Subject: wss4j-1.5.12 & Bouncy Castle

Hi,

I am faced in a peculiar problem that involves multiple moving parts and 
components. We are using Axis2 1.4.1 which via Rampart 1.4 ends up using 
wss4j-1.5.2. When this version of wss4j initializes, it registers BC at slot 2 
in the javax.security.Security providers list. This initialization done 
automatically and cannot be bypassed unless BC is registered already at some 
other spot. The byproduct of all this is the Tomcat's NIO SSL connector either 
stops working with bcprov 1.5.0 or intermittently stops working for latest 
bcprov 1.5.2. All this is very complicated, because it has to do with the 
negotiation of SSL and which protocol and which algorithm suite is being 
selected. There is definitely an issue with Bouncy Castle's GCMBlockCipher 
which ends up being used in a TLS1.2 connection b/w Chrome and FF and Tomcat 
7.0.61's NIO SSL connector which results in " bad_record_mac ". That's a 
question for the BC's dev list.

What I want to know is why does wss4j-1.5.12 insist on registering BC on slot 
2. It's been a while since it has been released and may be those day's JREs 
didn't have the algorithmic suits needed for SOAP security...

If I have to work around this BC issue by pre-registering BC at some other slot 
so its GCM block cipher doesn't end up being use, which slot is it safe to use? 
And is it safe to say that wss4j-1.5.12 doesn't really need BC's crypto to do 
signature, etc...

George

---------------------------------------------------------------------
To unsubscribe, e-mail: 
[email protected]<mailto:[email protected]> For 
additional commands, e-mail: 
[email protected]<mailto:[email protected]>


---------------------------------------------------------------------
To unsubscribe, e-mail: 
[email protected]<mailto:[email protected]>
For additional commands, e-mail: 
[email protected]<mailto:[email protected]>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to