Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.5
-
None
-
Windows XP
Description
I am using Axis2 1.5.1 and Rampart 1.5 to sign a SOAP request and validate the signature on the response, however I am getting a mismatch between the actual digest in the XML Signature in the response message and the digest produced by Rampart.
To investigate this issue, I implemented a simple Crypto provider that implemented the SHA1 digest algorithm. The provider just writes out the data that was sent to it to digest to a file. It then just calls the default Sun implementation to actually compute the digest. This allowed me to see the XML that Rampart was passing to the digest algorithm.
The attached input.xml is the initial signed response document.
When verifying the signature on the response body, rampart produces the following output:
> WARNING: Expected Digest: uf7xYFDKnUgQgxBg3SJTSIY/osk=
> 26-Jul-2010 10:54:56 org.apache.xml.security.signature.Reference verify
> WARNING: Actual Digest: uGqjmTDx7IDyniF7hh5eaQ2ZWjU=
I've taken the message and verified it successfully with a number of XML signature implementations, including the Apache one at
https://svn.apache.org/repos/asf/xml/security/tags/J_1_4_2, which is the version that rampart actually uses (i.e. xmlsec-1.4.2.jar ships with Rampart 1.5).
The attached file correct.dat is the c14n'd form of the body such that SHA1(correct.dat) matches the digest in the signature:
> $ openssl sha1 -binary correct.dat | openssl base64
> uf7xYFDKnUgQgxBg3SJTSIY/osk=
You can see that this digest matches the "Expected Digest" in the Rampart trace above, which is the digest in the XML Signature.
The attached file incorrect.dat is the data as passed to the digest via rampart:
> $ openssl sha1 -binary incorrect.dat | openssl base64
> uGqjmTDx7IDyniF7hh5eaQ2ZWjU=
You can see that this digest matches the "Actual Digest" produced by Rampart in the trace above.
The differences between the two inputs looks as follows:
>
> — correct.dat 2010-07-26 11:08:54.000000000 +0100
> +++ incorrect.dat 2010-07-26 11:08:54.000000000 +0100
> @@ -1,8 +1,8 @@
> <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
>
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
y-utility-1.0.xsd"
> wsu:Id="Id-0000012a0e1a1572-00000000010a6723-3">
> <GetDirectionsResponse xmlns="http://www.ecubicle.net/webservices/">
> <GetDirectionsResult>
> - <drivingdirections xmlns="">
> - <route distanceToTravel=" 500 m" finalStep="false" id="0">
> + <drivingdirections>
> + <route>
> Head south on Grove St
> </route>
> <totalDistance>739 km</totalDistance>
You can see that rampart has dropped the xmlns="" attribute/namespace declaration from the "drivingdirections" element, and also the attributes from the route element (indeed, it seems that neither the attribute or namespace axes have been entirely eliminated).
Experimentation shows that naiively deleting the default namespace declaration (i.e. xmlns="") from the drivingdirections element actually produces a signature that rampart can verify, so it is not just systematically eliminating theses axes.
This bug seems to resemble Issue 128, but this was logged in December 2007 for Rampart 1.3 and is still open. And since i had a bit more information I thought I'd add it in as a new issue.
https://issues.apache.org/jira/browse/RAMPART-128
You can see an example of a Web Service that returns elements in the empty namespace (i.e. xmlns="") here:
http://www.ecubicle.net/driving.asmx?wsdl
Attachments
Attachments
Issue Links
- blocks
-
-
- Open
-
- is blocked by
-
-
- Closed
-