-
1. Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
ctomc Mar 10, 2014 10:09 AM (in response to frodery)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
-
2. Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
asoldano Mar 10, 2014 10:10 AM (in response to frodery)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
-
3. Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
asoldano Mar 10, 2014 10:58 AM (in response to 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.
-
4. Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
frodery Mar 10, 2014 3:47 PM (in response to ctomc)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?
-
5. Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
frodery Mar 11, 2014 4:06 AM (in response to ctomc)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?
-
6. Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
ctomc Mar 10, 2014 6:32 PM (in response to frodery)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?
-
7. Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
asoldano Mar 11, 2014 4:24 AM (in response to frodery)1 of 1 people found this helpfulI 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.
-
8. Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
frodery Mar 11, 2014 4:17 AM (in response to ctomc)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.
-
9. Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
asoldano Mar 11, 2014 4:22 AM (in response to frodery)1 of 1 people found this helpfulThanks 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.
-
10. Re: Re: Re: Why did the order of JCE providers change from WildFly 8.0.0.CR1 to 8.0.0.Final?
frodery Mar 11, 2014 1:56 PM (in response to asoldano)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!