Can't get XML digests to match. Possible canonicalization problem? about xml-crypto

[yaronn]

Hi @archa347

Can you force passport to use [email protected] and check if that works?
I am not sure what is exactly the use case here but are you in position to strip any white space from the xml (on both client and server) before signing it? Which framework does the signatuere and which one the validation? Can you isolate the signing code in both frameworks and sign a smaller chunk of xml to see if that is identical?

[archa347]

I don't have much control over the server side, unfortunately. The XML is being generated and signed by a CA SIteMinder SAML identity provider. The passport-saml library does the validation on our end as the SAML consumer. The XML is sent over the wire as base64 encoded text. The XML text was base64 encoded with CRLF line endings. I found that after stripping CR's out of the text after decoding from base64 but before validation, it will pass. Otherwise, after c14n canonicalization we end up with 
 on the end of each line in addition to normal LF line endings. I also used xml-crypto with my base64 encoded text directly without using passport-saml and experienced the same issue. I did try with [email protected] and had the same issue.

[yaronn]

thanks

Which xml-crypto version do you have installed? Can you force passport to use [email protected] and check if that works? Following case #39 we have changed the xml parser dependency and this possibly affected the xml parsing.

[archa347]

passport-saml installs with [email protected]. I forced it to 0.1.25 and still had the same issues.

[yaronn]

thanks for the information

for now are you able to use the workaround you mentioned?
does the CRLF exist in the original xml or is it introduces only because the base64 is encoded with it? can you publish the base64?

[archa347]

The CRLF's are encoded in the base64, so I think they were part of the original XML as transmitted by the server. We do have a work-around in removing CR characters from the XML after decoding. I'll need to check to make sure I can post the full base64, I don't want to accidentally release any potentially secure information

[yaronn]

Do you use node to verify a signature that originates from a Microsoft .Net / Windows Store signature? trying to understand if this originates from this issue or not:
http://webservices20.blogspot.co.il/2013/06/validating-windows-mobile-app-store.html

[archa347]

No, the XML is coming from a proprietary software called SiteMinder by CA. Its a single sign on provider.

[matiasdecarli]

I'm struggling with this aswell. It seems like some problem regarding canonicalization, since the signature matching is OK (at least in my case), and theres no 
 in the XML

BTW Im using Okta in parallel and works fine. It seems like a problem with different IPs (maybe with the OS?)

[yaronn]

@matiasdecarli - if you remove white space is it also ok? also what do you mean that the signature match is ok - if the digests are different than the signature will also be different.
not sure I understand about the different IPs - your code works from some machines and from some not?

[matiasdecarli]

Using the ({ignoreWhiteSpace: true}) makes no difference. The calculated digest is the same, and doesnt match with the expected.

What I mean with the signature match is ok, is that validateSignatureValue() works fine, and the error is on validateReferences()

Regarding the IPs: yes. It works with Okta, but it fails when I'm using another one (Im not sure which one is since this is a 3rd party provider)

[yaronn]

ignoreWhiteSpace will not work with xmldom but only with xmldom-fork-fixed. instead, can you manually remove all whitespace, just to check? can you send me the xml and the signature?

[matiasdecarli]

Actually im using xmldom-fork-fixed => Dom = require('xmldom-fork-fixed').DOMParser. Additionally I created a function myself to strip whitespaces with the same result

This is specifically where the problem is (digest!=ref.digestValue)

[matiasdecarli]

Can I reach you via email to show you this stuff? Thanks in advance.

[yaronn]

sure, [email protected]

note that I will take a look once I have free time (this requires some
debugging and I need to find the right time for it)

On Thu, Apr 16, 2015 at 5:50 PM, Matias De Carli [email protected]
wrote:

Can I reach you via email to send you this stuff? Thanks in advance.

—
Reply to this email directly or view it on GitHub
#43 (comment).

I'm on Twitter (@YaronNaveh http://twitter.com/#!/YaronNaveh)

[matiasdecarli]

I totally understand, yes. Thanks

[matiasdecarli]

@yaronn Could you see the data? It looks like the encoding its the same, but the assertion has a different format. I've tried adding 
 at line endings with no luck

[yaronn]

Hi @matiasdecarli

I think I have found the issue. Since your XML is confidential I will send you the details in mail but I have opened a more general defect on this, #48 . I will send you a possible workaround.