[ http://issues.apache.org/jira/browse/WSS-24?page=comments#action_12356792 ]
Paul Grillo commented on WSS-24: -------------------------------- We are seeing the same problem that Samrat is seeing. In looking at the code that he refers to, it seems to me that he has a point here. It would appear to me that the long method "handleEncryptedKey" should declare decryptedBytes locally (on the stack, in the method). The only other access at the class level to decryptedBytes is a Public getter "public byte[] getDecryptedBytes()", which a) is not clear who uses it and b) whoever uses it will be getting something unsafe. If the public getDecryptedBytes() is really used or needed by somebody (I couldn't figure out where), that in addition to declaring decryptedBytes at the method level, you could copy it to a ThreadLocal variable and make it available through the getDecryptedBytes() call, assuming anybody is using it. It would at least provide backwared compatability Am I or Samrat misreading this? Do we at least agree that there seems to be a problem here and may cause the exception above? the same one i get spuriously? > Thread safety in WSDoAllReceiver using WSSecEngine > -------------------------------------------------- > > Key: WSS-24 > URL: http://issues.apache.org/jira/browse/WSS-24 > Project: WSS4J > Type: Bug > Environment: Windows 2000, JDK 1.4.2_06, 2 CPU, 2GHz > Reporter: Samrat Ketu > Assignee: Davanum Srinivas > > We have a multi-threaded program that uses Axis and WSS4J to send encrypted > messages to a web service and decrypts the contents as they are received. > We intermittently face the below exception - like 10 out of 5000 requests. > Typical number of threads running are 10, pumping 10 messages per second. As > you can see, the problem is happening while decrypting the response. > I was looking into the source code of WSS4J and realized that it could be > because of > a. the way session/symmetric key is stored in WSSecEngine (decryptedBytes > variable is used to store the session key and it is declared at the class > level) > b. the fact that reference to WSSecEngine is actually a static final variable > in WSHandler (which is extended ultimately by WSDoAllReceiver) > Apparently, all instances of WSDoAllReceiver use the same instance of > WSSecEngine to do encryption and decryption. And within WSSecEngine, the > symmetric key is a global variable, so different method invocations to > decrypt data will overwrite each other's symmetric key. > Exception is > org.apache.ws.security.WSSecurityException: Error Class: > org.apache.ws.security.WSSecurityException > Cannot encrypt/decrypt data; nested exception is: > org.apache.xml.security.encryption.XMLEncryptionException: pad block > corrupted > Original Exception was javax.crypto.BadPaddingException: pad block > corrupted > org.apache.ws.security.WSSecurityException: Cannot > encrypt/decrypt data; nested exception is: > org.apache.xml.security.encryption.XMLEncryptionException: pad > block corrupted > Original Exception was javax.crypto.BadPaddingException: pad block > corrupted > at > org.apache.ws.security.WSSecurityEngine.decryptDataRef(WSSecurityEngine.java:1226) > at org.apache.ws.security.WSSecurityEngine.handleEncryptedKey > (WSSecurityEngine.java:1171) > at > org.apache.ws.security.WSSecurityEngine.handleEncryptedKey(WSSecurityEngine.java:926) > at > org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java > :349) > at > org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:245) > at > org.apache.ws.axis.security.WSDoAllReceiver.invoke(WSDoAllReceiver.java:156) > at org.apache.axis.strategies.InvocationStrategy.visit > (InvocationStrategy.java:32) > at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) > at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) > at org.apache.axis.client.AxisClient.invoke (AxisClient.java:190) > at org.apache.axis.client.Call.invokeEngine(Call.java:2765) > at org.apache.axis.client.Call.invoke(Call.java:2748) > at org.apache.axis.client.Call.invoke(Call.java:2424) > at org.apache.axis.client.Call.invoke(Call.java:2347) > at org.apache.axis.client.Call.invoke(Call.java:1804) > .... > .... > Caused by: org.apache.xml.security.encryption.XMLEncryptionException > : pad block corrupted > Original Exception was javax.crypto.BadPaddingException: pad block > corrupted > at > org.apache.xml.security.encryption.XMLCipher.decryptToByteArray(Unknown > Source) > at org.apache.xml.security.encryption.XMLCipher.decryptElement > (Unknown Source) > at > org.apache.xml.security.encryption.XMLCipher.decryptElementContent(Unknown > Source) > at org.apache.xml.security.encryption.XMLCipher.doFinal(Unknown > Source) > at org.apache.ws.security.WSSecurityEngine.decryptDataRef > (WSSecurityEngine.java:1224) > ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
