Incorrect XML Passed to Digest Algorithm when XML Elements Belong to Empty
Namespace
------------------------------------------------------------------------------------
Key: RAMPART-303
URL: https://issues.apache.org/jira/browse/RAMPART-303
Project: Rampart
Issue Type: Bug
Components: rampart-core
Affects Versions: 1.5
Environment: Windows XP
Reporter: Niall Tierney
Assignee: Ruchith Udayanga Fernando
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=
The attached file incorrect.dat is the same reference as passed to the digest
via rampart:
> $ openssl sha1 -binary incorrect.dat | openssl base64
> uGqjmTDx7IDyniF7hh5eaQ2ZWjU=
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
