ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Stanchev <>
Subject RE: wss4j-1.5.12 & Bouncy Castle
Date Sat, 25 Apr 2015 23:11:26 GMT
The relevant code is [2]. At [1] we can see that Colm has chimed in so maybe he can comment
on this mess?




                // 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 =
                                ( c.newInstance(), i + 2
                if (ret == 0) {
                    ret =
                        ( c.newInstance(), 2

-----Original Message-----
From: George Stanchev [] 
Sent: Saturday, April 25, 2015 4:48 PM
Subject: wss4j-1.5.12 & Bouncy Castle


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


To unsubscribe, e-mail: For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message