Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?

[frodery]

Hi,

It seems that the order/priority of (JCE) cryptography providers changed from WildFly 8.0.0.CR1 to 8.0.0.Final. Invoking Cipher.getInstance("RSA/ECB/PKCS1Padding") from an application returns the SunJCE provider in WildFly 8.0.0.CR1, whereas BouncyCastle is returned in 8.0.0.Final.

I have not been able to figure out which change to WildFly introduced this. So I'm wondering if the change was intentional, or if it could be a bug and reversed in a future release? The answer to this affects my team on should handle the resulting bug in our application.

Thanks!

Best regards,

Frode Rystad

[ctomc]

Hey,

this change was introduced here https://github.com/wildfly/wildfly/commit/4199333f0a8195fbdb7443dd0217fee953e15862

But it could be also triggered by this change https://github.com/wildfly/wildfly/pull/5781

but, this should not be visible to your application by default.

What does your jboss-deployment-structure.xml looks like?

In any case, having BouncyCastle JCE returned cannot be bad thing for your app, as it supports much more cyphers than SunJCE does.

--

tomaz

[asoldano]

Hi,

would you mind providing a bit more info on the scenario? Where are you invoking Cipher.getInstance() ? (is it a ejb3, servlet, etc) Which module dependencies is your application declaring?

The change that is likely related to this was intentional, but we're evaluating if you're suffering from a ripple effect of it or what.

Btw, just to know, why is it relevant to you which provider is actually registered for a given algorithm?

Alessio

[asoldano]

As a side note, if the undesired behavior here comes from something the webservices subsystem is doing (which is still to be confirmed and why I'm asking for more info), you could try registering the BouncyCastle provider as last provider in your JDK; as a matter of fact, the webservices subsystem will be checking if BouncyCastle provider is available and only register it if it's not available. So you'd effectively preventing any change to the order of registered providers.

[frodery]

Thank you for your response, Tomaz!

A third party library we're using requires BouncyCastle, so we have declared a dependency on in in our jboss-deployment-structure.xml.

I reviewed the commits you suggested. In Final, BouncyCastle appears as number 2 in the list of registered security providers (Security.getProviders()), whereas it is not registered at all in CR1. I get this result regardless of whether or not BouncyCastle is a dependency in jboss-deployment-structure.xml, or whether i start WildFly with the default or full profile.

I was expecting a commit looking more like Security.insertProviderAt(new BouncyCastleProvider, 2).

Is it possible that the change was introduced by another commit?

[frodery]

Thank you for your response, Alessio!

I understand that you are puzzled as to why this is a problem to us We're using a third party library that invokes Cipher.getProvider("RSA/....").getBlockSize() to determine if the cipher is a block cipher. The SunJCE implementation returns 0 and BouncyCastle throws an IllegalStateException (which breaks features in our application). Getting this third party provider to change their implementation is an option, but we are also exploring other options.

As a fix, I now reorder the security providers upon application startup (exactly as you suggested). Our third party library now works just like before upgrading WildFly to Final. Only problem is, without understanding why the JCE provider order was changed between CR1 and Final, I have no idea which platform features I might have just broken

The invocation is from an EJB. Our application declares a dependency on BouncyCastle in jboss-deployment-structure.xml. Like stated in my previous comment, this does not seem to affect which JCE providers are registered with the JVM.

I have recreated the same result from a servlet running WildFly with the default standalone profile, and without declaring any dependencies from WildFly. The code below lists the registered JCE providers, in the preferred order. Try it on both CR1 and Final to see the difference. BouncyCastle only appears in Final, as number two in the list.

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.security.Provider;
import java.security.Security;


@WebServlet(urlPatterns = "/ListJceProviders")
public class ListJceProvidersServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        PrintWriter writer = response.getWriter();

        for (Provider provider : Security.getProviders()) {
            writer.println(provider.toString());
        }
    }
}

EDIT: The table below has been edited after the original post. It now shows the result of WildFly standalone, default profile, on Windows 7, running JDK 1.7 u51 with JCE Unlimited Strength. Similar results (BouncyCastle only in Final) are observed on other OS-es (OS X and Linux), and other WildFly configurations (standalone/domain and default/full profile).

WildFly 8.0.0.CR1	WildFly 8.0.0.Final
SUN version 1.7 ApacheXMLDSig version 1.55 SunRsaSign version 1.7 SunEC version 1.7 SunJSSE version 1.7 SunJCE version 1.7 SunJGSS version 1.7 SunSASL version 1.7 XMLDSig version 1.0 SunPCSC version 1.7 SunMSCAPI version 1.7 STRTransform version 1.6	SUN version 1.7 BC version 1.46 ApacheXMLDSig version 1.56 SunRsaSign version 1.7 SunEC version 1.7 SunJSSE version 1.7 SunJCE version 1.7 SunJGSS version 1.7 SunSASL version 1.7 XMLDSig version 1.0 SunPCSC version 1.7 SunMSCAPI version 1.7 STRTransform version 1.6

Do you have any specific change in mind, that could have introduced this?

[ctomc]

Looking at your list of providers in .CR1 and .Final

It looks like that CR1 was/is running under JDK8 but .Final is running under JDK7.

That could explain all your issues.

Can you make sure you run both with same JDK and try to reproduce issue?

[asoldano]

I reviewed the commits you suggested. In Final, BouncyCastle appears as number 2 in the list of registered security providers (Security.getProviders()), whereas it is not registered at all in CR1. I get this result regardless of whether or not BouncyCastle is a dependency in jboss-deployment-structure.xml, or whether i start WildFly with the default or full profile.

I was expecting a commit looking more like Security.insertProviderAt(new BouncyCastleProvider, 2).

Is it possible that the change was introduced by another commit?

Actually no. Something like Security.insertProviderAt(new BouncyCastleProvider, 2) is what Apache CXF does the first time the ws-security engine is initialized (during boot). That only happens if BouncyCastle is available, that is if it is actually included in the JDK or there's the module dependency that Tomaz pointed to.

The reason for having added the dependency is that this way you don't have to manually install BouncyCastle in your JDK to use all the WS-Security functionalities of the webservices stack.

[frodery]

Thank you, Tomaz!

I created that output on my OS X home computer, after putting the kids to bed last night. I thought it would save time, and bring this case faster forward. But I forgot to set JAVA_HOME on the console running CR1. That explains the odd output with differing versions, which you observed. My mistake! Sorry about the confusion

Now I'm back at work and have rerun the output, making sure that only the WildFly versions differ. I have updated the table in my previous comment.

All my colleagues experience the same issue, and on multiple platforms and configurations, so I'm quite sure that this is a real change from CR1 to Final, and not something we're doing wrong

Any help in identifying which issue introduced the change will be appreciated, as it will influence how our team will handle the side effect in our application.

[asoldano]

Thanks for the explanation Frode.

Frode Rystad wrote:

The table below has been edited after the original post. It now shows the result of WildFly standalone, default profile, on Windows 7, running JDK 1.7 u51 with JCE Unlimited Strength. Similar results (BouncyCastle only in Final) are observed on other OS-es (OS X and Linux), and other WildFly configurations (standalone/domain and default/full profile).

WildFly 8.0.0.CR1	WildFly 8.0.0.Final
SUN version 1.7 ApacheXMLDSig version 1.55 SunRsaSign version 1.7 SunEC version 1.7 SunJSSE version 1.7 SunJCE version 1.7 SunJGSS version 1.7 SunSASL version 1.7 XMLDSig version 1.0 SunPCSC version 1.7 SunMSCAPI version 1.7 STRTransform version 1.6	SUN version 1.7 BC version 1.46 ApacheXMLDSig version 1.56 SunRsaSign version 1.7 SunEC version 1.7 SunJSSE version 1.7 SunJCE version 1.7 SunJGSS version 1.7 SunSASL version 1.7 XMLDSig version 1.0 SunPCSC version 1.7 SunMSCAPI version 1.7 STRTransform version 1.6

Do you have any specific change in mind, that could have introduced this?

The change in the list of providers is what I'd expect for the scenario in which BouncyCastle is not already installed in the JDK.

As explained in the previous post, the reason is the added dependency + Apache CXF registering BC if available.

You can most likely move the BC provider in different positions without problems. As far as webservices subsystem is concerned, it should work in any position, as it's needed for algorithms that are not provided by any of the default providers.

[frodery]

Ok, I am satisfied with the answers Let me reiterate my current understanding of the issue:

The change was introduced by this commit to jbossws, as Tomaz Cerar pointed out in his first post I tried removing exactly that line from my 8.0.0 Final configuration, and the CR1-behaviour was back again.

It is not entirely correct, like ctomc and asoldano states, that BouncyCastle is not visible to the application by default. Because jbossws is now depending on module org.bouncycastle, then BouncyCastleProvider is registered as a JCE provider with java.security.Security (in index 2). This allows my application to use BouncyCastle through the JCE APIs without declaring a dependency on the module org.bouncycastle.

The JBoss module system does however prevent me from instantiating BouncyCastleProvider directly. For that, I would have to declare the dependency to module org.bouncycastle.

My team will continue using our workaround, which is to reorder the JCE providers upon application startup - at least until we get a fix from our third party library provider. I guess CXF registered BouncyCastle as provider number 2 for a reason, so I'm prepared that some problems may appear.

If anybody is interested, I pushed the tool I used while investigating this to GitHub. Visit my project, list-jce-providers.

This was my first post to this forum, and I must say I am really impressed with the assistance you gave. Thank you so much for your help, guys!