ws-wss4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Grillo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (WSS-24) Thread safety in WSDoAllReceiver using WSSecEngine
Date Fri, 04 Nov 2005 15:30:20 GMT
    [ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org


Mime
View raw message