[
https://issues.apache.org/jira/browse/CAMEL-26425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Babak Vahdat updated CAMEL-26425:
---------------------------------
Fix Version/s: 4.24.0
> camel-as2 - signature verification and MDN MIC are computed over a
> re-serialisation of the signed part, not over the bytes received
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26425
> URL: https://issues.apache.org/jira/browse/CAMEL-26425
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
> Affects Versions: 4.22.0
> Reporter: Babak Vahdat
> Assignee: Babak Vahdat
> Priority: Minor
> Fix For: 4.18.6, 4.22.3, 4.24.0
>
>
> An AS2 server built on camel-as2 (as2:server/listen) refuses a correctly
> signed message with the MDN
> disposition "processed/error: authentication-failed" when the signed part uses
> Content-Transfer-Encoding: base64 or quoted-printable and was produced by
> another AS2 implementation
> (openssl cms, Lobster_data, OpenAS2, ...). The same message sent as binary,
> 7bit or 8bit is accepted.
> Cause: SigningUtils.isValid(MultipartSignedEntity, Certificate[]) serialises
> the parsed first body part
> again (MimeEntity.writeTo) and verifies the signature over that. The
> re-serialisation re-encodes the
> decoded content with camel-as2's own encoder (base64 wrapped at 76
> characters, quoted-printable with its
> own escaping) and rewrites the headers, so it differs from the bytes the
> sender signed whenever the
> sender's encoding differs in line length or escaping. RFC 1847 section 2.1
> defines the signature over the
> first body part as transmitted, headers included, after the transfer encoding
> is applied.
> For the same reason MicUtils.createReceivedContentMic computes the
> Received-Content-MIC of the MDN over
> the re-serialised part, so the MIC in the receipt does not match the one the
> sender computed over what it
> sent (RFC 4130 section 7.1) - the sender's MDN check fails even for an
> accepted message.
> camel-as2's own client is not affected, because client and server re-encode
> identically; that is why the
> component's tests never show it.
> Reproduction:
> - Unit test (in the pull request): sign the bytes
> "Content-Type: application/edifact\r\nContent-Transfer-Encoding:
> base64\r\n\r\n" + base64 of the
> payload wrapped at 64 characters
> with a detached PKCS#7 signature (BouncyCastle, as openssl cms -sign does),
> assemble the
> multipart/signed, parse it with EntityParser.parseEntity and call
> SigningUtils.isValid: false. The same
> with a quoted-printable part that escapes characters camel-as2 would not
> escape.
> - By hand: openssl cms -sign over such a part, openssl cms -encrypt for the
> server's certificate, POST
> with curl to as2:server/listen - the MDN says processed/error:
> authentication-failed. Seen in
> production-like use with Lobster_data as the partner: small EDI files (sent
> binary) accepted, larger
> ones (sent base64) refused.
> Fix (pull request follows):
> - The parser keeps the first body part of a multipart/signed exactly as
> received
> (AS2SessionInputBuffer raw capture,
> MultipartSignedEntity.getSignedDataRaw()).
> - SigningUtils.isValid and MicUtils use those bytes
> (MultipartSignedEntity.getSignedDataContent()),
> falling back to the serialisation for entities built locally, so the client
> side is unchanged.
> - Tests MultipartSignedEntityAsReceivedTest (base64, quoted-printable and
> binary parts; inside an
> encrypted message; a locally built entity) and AS2SessionInputBufferTest.
> - Upgrade guide entry for 4.24.
> _This text was prepared with Claude Code (Claude Fable 5.1) on behalf of
> Babak Vahdat (bvahdat), who analysed, reproduced and verified the issue._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
