[
https://issues.apache.org/jira/browse/CXF-6955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128537#comment-18128537
]
Freeman Yue Fang commented on CXF-6955:
---------------------------------------
I checked whether this still happens on the current code base, and it does. I
attached a standalone reproducer, cxf-6955-reproducer.zip. It runs with {{mvn
test}}, or {{mvn test -Dcxf.version=...}} for another CXF version.
Setup: A WS-RM client sends a one-way message with a SOAP with Attachments
attachment. The attachment is either not secured, encrypted
({{encryptionParts={}cid:Attachments;}}) or signed together with the Body
({{signatureParts=...Body;{}cid:Attachments;}}) by the {{WSS4JOutInterceptor}}.
A message loss simulator drops the first transmission, so the server only ever
receives the WS-RM retransmission. Client and server run in the same JVM.
Results:
||Test||4.2.4||4.2.5-SNAPSHOT with the CXF-9258 fix||
|plain / encrypted / signed, no message loss|passes|passes|
|encrypted attachment, retransmitted|fails (CXF-9258)|fails: 0 bytes received|
|signed attachment, retransmitted|fails (CXF-9258)|fails: 0 bytes received|
On a released version, CXF-9258 masks this issue: no retransmission with
attachments works, secured or not, and the server rejects them with {{Couldn't
find MIME boundary}}. Once CXF-9258 is fixed, plain attachments are
retransmitted correctly. Encrypted and signed attachments, however, arrive
empty:
{noformat}
AssertionFailedError: received 0 bytes: "" ==> array lengths differ, expected:
<30> but was: <0>
{noformat}
The server accepts these messages without any security error, because the empty
attachment is correctly encrypted or signed. So the attachment content is lost
silently.
Cause: When securing attachments, WSS4J (through the
{{AttachmentCallbackHandler}}) replaces the entries of
{{message.getAttachments()}} with attachments whose content is a stream of the
secured data, which can only be read once. WS-RM retransmits the same message
instance, so the retransmission secures the already consumed streams again.
Possible fix: Keep the original, unsecured attachments when the message is
captured for retransmission, and apply the security processing to them again on
each retransmission, instead of reusing the attachments produced by the first
one. Reusing the secured attachments from the first transmission wouldn't work,
because the security header written on each retransmission must match the
attachment content it secures.
This depends on CXF-9258, which fixes the retransmission of messages with
attachments in general.
> WS-RM 3.x encrypted attachments are saved for retransmission
> ------------------------------------------------------------
>
> Key: CXF-6955
> URL: https://issues.apache.org/jira/browse/CXF-6955
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 3.1.6, 3.0.9
> Reporter: Kai Rommel
> Assignee: Freeman Yue Fang
> Priority: Major
>
> The security processed attachments themselves are reusable for retransmission
> because there is no timestamp attached to them. However, the retransmission
> will currently re-apply security processing to the attachments and that will
> be wrong.
> There are some options to solve the issue:
> 1. To re-use the processed attachments, we need to skip security processing
> for the attachments at retransmission.
> 2. Alternatively, we could store the original attachments when ws-sec on
> attachments is configured and apply security processing at each
> retransmission.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
