You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Samisa Abeysinghe (JIRA)" <ji...@apache.org> on 2010/12/22 00:10:01 UTC
[jira] Resolved: (RAMPART-303) Incorrect XML Passed to Digest
Algorithm when XML Elements Belong to Empty Namespace
[ https://issues.apache.org/jira/browse/RAMPART-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Samisa Abeysinghe resolved RAMPART-303.
---------------------------------------
Resolution: Fixed
Fix Version/s: NextVersion
Fixed with the fix for RAMPART-309
> 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
> Fix For: NextVersion
>
> Attachments: correct.dat, driving_with_wspolicy.wsdl, DrivingClient.java, incorrect.dat, input.xml
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org