RFI, community, re: Transmitting from Oxalis 4.1.0 to Oxalis 4.0.2

[OysteinLq]

There's been a couple of prior issues regarding a bugfix in Oxalis 4.0.3'ss handling of digests. Notably https://github.com/difi/oxalis/issues/424 and https://github.com/difi/Oxalis-AS4/issues/48 This /seems/ to be a significant problem for us, because we've been unable to upgrade our Outbound because it makes us uncompatible with a number of major access points.

We've recently upgraded our local Peppol AP from 4.0.3 to 4.1.0 and have found that there are a number of APs that we are now unable to distribute to via AS2. Because of this, we downgraded our Outbound to 4.0.3, and immediately the same files were distributed OK. We've tried 4.1.0 in both noop and legacy mode, with the same results. The error message from the APs we're sending to is invariably "Invalid message digest."

Since a number of APs have upgraded, I'm curious if anyone have had to write workarounds for this issue. Do you run multiple Outbound nodes with different versions of Oxalis, or do you recognize the error and programatically try "the old way"?

I see @klakegg commented on November 12th that

access points providers should update their Oxalis installations rather than running releases not containing more than a year worth of fixes and dependency updates (security!)

It feels like we're at the mercy of other APs at this point. Are there other companies out there holding off on an upgrade because of this?

FWIW: the servers we see problems with are reporting that they're using Oxalis 4.0.2 or 4.0.3-RC0

I apologize if this is the wrong forum for this. I do not know of any other community forum for access points using Oxalis.

[PPotappel]

Same problem here! We scan for the text "invalid message digest". If we find it, we retry with old 4.0.3 stand alone....

[OysteinLq]

Thanks for your response @PPotappel -- we might end up having to do something along those lines as well.

The requirement that everyone must support AS4 from February 1st does seem like it will force most companies' hands on this (and is indeed why we're working on upgrading.)

I did get a direct response from someone that at least one major Norwegian AP have upgraded their outbound and simply stopped sending to APs that don't support it. Presumably they're defaulting to some alternative method of delivering the documents. I guess this sort of intra-network peer pressure might do the trick, but it seems a bit unprofessional.

[artjomsk]

We're holding on upgrade from 4.0.4 to 4.1.0, because of another issue (similar, but with AS4) - https://github.com/difi/Oxalis-AS4/issues/46 (OK, maybe Oxalis 4.1.0 can work with older AS4 RC) UPD: We haven't tried 4.1.0 on production, so, haven't seen "invalid message digest" from some major AP as you say

Thanks for question, because we also don't understand general upgrade strategy and don't really want to implement hacks with multiple standalone Oxalis versions like @PPotappel mentioned. That's why it's very interesting topic.

[rdehuyss]

We are also bumping into this issue...

We found the root cause (thanks to a collegue of mine): if a sender sends a document over AS2 with Oxalis 4.1.0 to a receiver with Oxalis 4.0.4, the message digest verification fails with the error mentioned here.

The reason is a change in commit d22399406a5fb1575c69b1d64b2825c4ec287276 in Oxalis where the MimeMessageHelper changed from mimeBodyPart.setHeader("Content-Transfer-Encoding", "binary"); to mimeBodyPart.setHeader("Content-Transfer-Encoding", "base64");

Reverting this appears to solve the issue.

Using this fix, we were able to send files to receivers using Oxalis 4.0.2 and Oxalis 4.1.0. Using the patched Oxalis, we tested the following scenario's and all looks ok.

From \ To	Oxalis 4.0.x	Oxalis 4.1.0 with AS4 support
Oxalis 4.0.x	AS2: OK AS4v2: NA	AS2: ? AS4v2: NA
Oxalis 4.1.0 with AS4 support	AS2: NOK (message digest error) AS4v2: NA	AS2: OK AS4v2: OK
Oxalis 4.1.0 patched with AS4 support	AS2v1: OK AS2v2: NA AS4v2: NA	AS2v1: OK AS2v2: OK AS4v2: OK

[OysteinLq]

Huh, I just saw your edit @rdehuyss . Thanks for the detailed information, and well done spotting the root cause.

@klakegg I don't imagine commit d223994 was made just for the hell of it -- do you know if reverting it could lead to other problems? Is it a security issue?

Our (Logiq's) inbound is currently running Oxalis 4.1.0, with both AS2 and AS4, which works fine. We have tried sending AS2 messages from our 4.0.4 outbound to our 4.1.0 inbound, and that works fine as well. So it seems the problem is limited to sending from 4.1.0 to 4.0.X via AS2. In /theory/ that shouldn't be a problem after February 1st, but I have my doubts, hence the scrambling for alternative solutions, such as running multiple outbounds or indeed modding Oxalis directly.

[mindweaver]

This issue is really hurting us at the moment.

Can someone create a standalone.jar with rdehuyss's fix? Not sure I am able to compile one myself.

EDIT: I managed to complie myself, and it seems to be working. A official fix for this would be nice going forward!

[ri4a]

IMO https://github.com/difi/oxalis/commit/d22399406a5fb1575c69b1d64b2825c4ec287276 should be reverted to allow service providers who are on 4.1.0 and are ready for AS4, but still have to send to non-compliant AS2-only <= 4.0.3 service providers, to continue to deliver an uninterrupted service for their clients.

[HarshaSuranjith]

We are currently facing this issue as well. all AS2 messages sent to Oxalis 4.0.2 instances fails with

Disposition: automatic-action/MDN-sent-automatically; failed/error: integrity-check-failed

and server returns

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

= Received headers

date: Fri, 31 Jan 2020 11:12:04 +0100
message-id: <1580465524622.92.1199293302.Oxalis@XXXX>
subject: AS2 message from Oxalis
mime-version: 1.0
content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_274_1522755386.1580465524622"
as2-from: PNO000XXX
as2-to: PNO000XXX
disposition-notification-to: not.in.use@difi.no
disposition-notification-options: signed-receipt-protocol=required,pkcs7-signature; signed-receipt-micalg=required,sha1
as2-version: 1.0
host: peppol.xxxxxx.net:8443
connection: Keep-Alive
user-agent: Oxalis 4.1.0
accept-encoding: gzip,deflate
content-length: 170709

= Error [untracked:fa67538d-be50-4817-abc4-f0808521d688]

Invalid message digest.

------=_Part_1489924_599154834.1580465883871
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit

Reporting-UA: Oxalis 4.0.2
Original-Recipient: rfc822; PNO000XXX
Final-Recipient: rfc822; PNO000XXX
Original-Message-ID: <1580465883361.103.-123026275.Oxalis@XXXX>
Disposition: automatic-action/MDN-sent-automatically; failed/error: integrity-check-failed

@klakegg is it possible to revert https://github.com/difi/oxalis/commit/d22399406a5fb1575c69b1d64b2825c4ec287276 without any disruptions ?