[
https://issues.apache.org/jira/browse/RAMPART-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Tierney updated RAMPART-303:
----------------------------------
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
was:
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
> 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
> Attachments: correct.dat, 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.
