MIC calculation on outgoing AS2 is incorrect when using compress before signing

[jthompsonnp]

Using as2lib as both client and server. When sending a non-compressed, or a compressed after signed file, the MIC for the MDN is matched as MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5

But when using compress before sign, the original MIC is MIC: bMUIBjelUf5Zy+kPrtaMRw==, md5. And the MIC for the MDN is MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5

MIC IS NOT MATCHED; original MIC: bMUIBjelUf5Zy+kPrtaMRw==, md5 received MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5 [<local-20220802-115713-0300-4490@local_ec2Key>]

It seems that within the secure method of the AS2SenderModule, the data is cleared, and the original MIC is calculated with blank data as an input. However the actual as2 message that is sent has the correct data and thus the MDN is sent with the 'correct' MIC

[phax]

I think I understand the problem.
Officially the AS2 RFC defines a way how to do things (compress before sign or sign before compress). I need to check which one is correct. The other solution is just a workaround per se... I need to check

[jthompsonnp]

Compress before signing seems to be the default. But this is the only one that I am having trouble with.

[phax]

Ok. Quote from RFC 5402, chapter 3

When compressing a document that will be signed, the application MAY compress the innermost MIME body before signing (see Sections 3.2 and 3.5), or it MAY compress the outer multipart/signed MIME body (see Sections 3.3 and 3.6), but it MUST NOT do both within the same document. The receiving application MUST support both methods of compression when unpackaging an inbound document.

And chapter 4.1. MIC Calculation for Signed Message

For any signed message, the MIC to be returned is calculated over the same data that was signed in the original message as per [AS1]. The signed content will be a MIME bodypart that contains either compressed or uncompressed data.

[jthompsonnp]

So it should work with compress BEFORE sign and with compress AFTER sign. But I'm getting a "MIC IS NOT MATCHED; " error whenever I test compress before sign.

Is there a reason why this is happening?

1. No compression - Original MIC and Returned MIC are matched as MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5
2. Compress after sign - Original MIC and Returned MIC are matched as MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5
3. Compress before sign - MIC IS NOT MATCHED; original MIC: bMUIBjelUf5Zy+kPrtaMRw==, md5 received MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5

Even though the data I'm transferring is the same with all tests?

[jthompsonnp]

To add to this, when testing AS2Lib -> Mendelson. This is what I get:

1. No compression ------- MIC is matched, MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5
2. Compress after sign --- MIC is matched, MIC: Xc9uKhufeGS/tEPvxjbe9g==, md5
3. Compress before sign - MIC is matched, MIC: bMUIBjelUf5Zy+kPrtaMRw==, md5

So it looks like the MIC is calculated the same with No Compression as it is with Compress After Sign. But with Compress Before Sign, the MIC is calculated differently resulting in a different MIC.

However when testing AS2Lib -> AS2Lib, the received MIC for Compress Before Sign is the same as the original MIC for No Compression and Compress After Sign. Which makes me believe that it is being calculated incorrectly.

[phax]

Thanks for your thorough analysis 👍🏼
I just currently don't have the immediate capacity to process your issue. But you provided all the relevant information!

[phax]

I checked with the latest version (4.11.0-SNAPSHOT) with my MainSendToMendelsonTestServerPlayground example application, using MD5 as the signing algo and 3des as the (insecure) encryption algorithm:

1. No compression: NcyVevXfkQbXw9ydKLxcyw==, md5
2. Compress after sign: NcyVevXfkQbXw9ydKLxcyw==, md5
3. Compress before sign: otv2eEXDRF2gW2xMPme5IA==, md5

In all 3 cases the MIC is matched by Mendelson. So my assumption is, that the sending MIC calculation works as expected.

But as you mentioned the as2lib-as2lib sending has issues, so maybe I should focus on the MIC calculation for incoming message.

[jthompsonnp]

Yes, I believe that's where the issue is occurring.

Thank you for taking a look at this issue. Let me know if you need any more information from me to recreate it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.