Skip to content
Original file line number Diff line number Diff line change
Expand Up @@ -11,22 +11,26 @@
import javax.crypto.Cipher;
import java.nio.ByteBuffer;
import java.security.GeneralSecurityException;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicLong;

public class CipherSubscriber implements Subscriber<ByteBuffer> {
private final AtomicLong contentRead = new AtomicLong(0);
private final Subscriber<? super ByteBuffer> wrappedSubscriber;
private Cipher cipher;
private final Cipher cipher;
private final Long contentLength;
private boolean isLastPart;
private final boolean isLastPart;
private final int tagLength;
private final AtomicBoolean finalBytesCalled = new AtomicBoolean(false);

private byte[] outputBuffer;

CipherSubscriber(Subscriber<? super ByteBuffer> wrappedSubscriber, Long contentLength, CryptographicMaterials materials, byte[] iv, boolean isLastPart) {
this.wrappedSubscriber = wrappedSubscriber;
this.contentLength = contentLength;
cipher = materials.getCipher(iv);
this.cipher = materials.getCipher(iv);
this.isLastPart = isLastPart;
this.tagLength = materials.algorithmSuite().cipherTagLengthBytes();
}

CipherSubscriber(Subscriber<? super ByteBuffer> wrappedSubscriber, Long contentLength, CryptographicMaterials materials, byte[] iv) {
Expand All @@ -46,20 +50,50 @@ public void onNext(ByteBuffer byteBuffer) {
if (amountToReadFromByteBuffer > 0) {
byte[] buf = BinaryUtils.copyBytesFrom(byteBuffer, amountToReadFromByteBuffer);
outputBuffer = cipher.update(buf, 0, amountToReadFromByteBuffer);

if (outputBuffer == null || outputBuffer.length == 0) {
// The underlying data is too short to fill in the block cipher.
// Note that while the JCE Javadoc specifies that the outputBuffer is null in this case,
// in practice SunJCE and ACCP return an empty buffer instead, hence checks for
// null OR length == 0.
if (contentRead.get() == contentLength) {
if (contentRead.get() + tagLength >= contentLength) {
// All content has been read, so complete to get the final bytes
this.onComplete();
finalBytes();
Copy link

@davidconnard davidconnard May 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @kessplas

Is the lack of calling onComplete() after finalBytes() deliberate? There seems to be a change in behaviour here. edit: this doesn't seem to be a problem, I've downloaded the src directly and confirmed that re-adding it makes no difference.

FWIW, I'm looking into a failure in our software that has been introduced with v3.3.3 of this SDK, and it seems to relate to our Kotlin Flows not completing normally and instead "cancelling", which leads to our completion handlers not firing properly. My current working theory is that the missing onComplete() here is leading to the Kotlin cancellation, when the upload Flow has completed sending all ByteBuffers and shutdown, but without the subscriber having properly called onComplete(). edit: this is not the case, and I'm still confused

Any idea what might be going on here? Are you sure that this change was safe?

Copy link
Contributor Author

@kessplas kessplas May 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @davidconnard ,

This change made the CipherSubscriber more spec compliant as onNext() MUST be only called once for one onNext() signal. The spec is not abundantly clear about the validity of signaling onComplete() from within onNext() but intuitively, the onComplete() signal should come from the publisher once all data is published and flow through the subscribers accordingly; calling onComplete() from within onNext() subverts this expectation.

We don't specifically support Kotlin, as we don't test against the Kotlin SDK. That said, I would recommend opening an issue for this, as it's easier for us to track than comments on a specific PR. Thanks!

Copy link

@davidconnard davidconnard May 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kessplas for the response ... Yesterday, I didn't yet have enough information to raise an issue. I've done some further digging, and I've uncovered where the change in behaviour is coming from.

In the AWS SDK, in the netty-nio-client, in the NettyRequestExecutor.StreamedRequest class, in the onNext() method, there is a check for shouldContinuePublishing(), which checks if the content-length has been reached. When it has been reached, the subscription is cancelled, and an onComplete() call is made. See https://github.com/aws/aws-sdk-java-v2/blob/7009f86260a3d77f811c1dde31679d1297c1cc01/http-clients/netty-nio-client/src/main/java/software/amazon/awssdk/http/nio/netty/internal/NettyRequestExecutor.java#L453-L456

It is this subscription cancellation that is causing my test failure. Encountering this subscription cancellation behaviour is new (as far as my test is concerned). Before this change, the final content-length would only be reached (ie. final bytes sent) as a side-effect of the onComplete() call, and the subscription cancellation would have no actual effect (ie. would not fire on onError() for the publisher). With your changes, the final content-length is reached in the terminal onNext() call, and the cancellation (triggered by the AWS SDK) fires at that point (prior to publisher completion), leading to an onError() call, which triggers different completion behaviour in the Kotlin Flow.

So, this isn't a problem with your change, and apologies for that! Previously, the CipherPublisher was hiding this early cancellation behaviour of the AWS SDK from our flow, and your change has simply exposed our code to this behaviour in the underlying AWS SDK. If I remove the AWS S3 Encryption SDK from the picture, and apply our Flow transformer (with its completion handler) over the raw AWS S3 SDK, then I see the exact same behaviour - our completion handler is invoked (with an error) after cancellation of the subscription/flow).

The solution for us appears to be to restructure our flow / publisher logic. For reference, when our requests to S3 are using the AWS S3 encryption SDK (which is not all the time), we are wrapping the byte stream publisher in another publisher, which performs additional verification of the plaintext (original bytes) checksum prior to sending to S3. To date, we had used onNext() calls to accumulate the plaintext checksum, and we performed the verification in the onComplete() call. While that worked, on reflection, it does not seem to be the correct way to verify this, and it only worked because of the CipherSubscriber previously delayed sending the final bytes to S3 (and therefore, delayed the cancellation) until the onComplete() call (rather than having it fire from the terminal onNext() call).

The right solution seems to be to change our code to perform the verification in the terminal onNext() call (by tracking the byte count, like the AWS SDK is doing). This will verify the plaintext checksum before sending the final bytes to the wrapped subscriber (ie. CipherSubscriber) in the chained onNext() call.

return;
}
// Otherwise, wait for more bytes. To avoid blocking,
// send an empty buffer to the wrapped subscriber.
wrappedSubscriber.onNext(ByteBuffer.allocate(0));
} else {
wrappedSubscriber.onNext(ByteBuffer.wrap(outputBuffer));
/*
Check if stream has read all expected content.
Once all content has been read, call onComplete.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Once all content has been read, call onComplete.
Once all content has been read, call finalBytes.

This determines that all content has been read by checking if
the amount of data read so far plus the tag length is at least the content length.
Once this is true, downstream will never call `request` again
(beyond the current request that is being responded to in this onNext invocation.)
As a result, this class can only call `wrappedSubscriber.onNext` one more time.
(Reactive streams require that downstream sends a `request(n)`
to indicate it is ready for more data, and upstream responds to that request by calling `onNext`.
The `n` in request is the maximum number of `onNext` calls that downstream
will allow upstream to make, and seems to always be 1 for the AsyncBodySubscriber.)
Since this class can only call `wrappedSubscriber.onNext` once,
it must send all remaining data in the next onNext call,
including the result of cipher.doFinal(), if applicable.
Calling `wrappedSubscriber.onNext` more than once for `request(1)`
violates the Reactive Streams specification and can cause exceptions downstream.
*/
if (contentRead.get() + tagLength >= contentLength) {
// All content has been read; complete the stream.
// (Signalling onComplete from here is Reactive Streams-spec compliant;
// this class is allowed to call onComplete, even if upstream has not yet signaled onComplete.)
finalBytes();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// All content has been read; complete the stream.
// (Signalling onComplete from here is Reactive Streams-spec compliant;
// this class is allowed to call onComplete, even if upstream has not yet signaled onComplete.)
finalBytes();
// All content has been read; compute finalBytes
finalBytes();
} else {
// Needs to read more data, so send the data downstream,
// expecting that downstream will continue to request more data.
wrappedSubscriber.onNext(ByteBuffer.wrap(outputBuffer));
}
}
} else {
// Do nothing
Expand Down Expand Up @@ -91,21 +125,63 @@ public void onError(Throwable t) {

@Override
public void onComplete() {
// In rare cases, e.g. when the last part of a low-level MPU has 0 length,
// onComplete will be called before onNext is called once.
if (contentRead.get() < contentLength) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this calculation include the tag length?
It feels weird that this formula is different than the other ones

Suggested change
if (contentRead.get() < contentLength) {
if (contentRead.get() + tagLength < contentLength) {
finalBytes();
}
wrappedSubscriber.onComplete();
}

/**
* Finalize encryption, including calculating the auth tag for AES-GCM.
* As such this method MUST only be called once, which is enforced using
* `finalBytesCalled`.
*/
private void finalBytes() {
if (!finalBytesCalled.compareAndSet(false, true)) {
// already called, don't repeat
return;
}

// If this isn't the last part, skip doFinal and just send outputBuffer downstream.
// doFinal requires that all parts have been processed to compute the tag,
// so the tag will only be computed when the last part is processed.
if (!isLastPart) {
// If this isn't the last part, skip doFinal, we aren't done
wrappedSubscriber.onComplete();
wrappedSubscriber.onNext(ByteBuffer.wrap(outputBuffer));
return;
}

// If this is the last part, compute doFinal and include its result in the value sent downstream.
// The result of doFinal MUST be included with the bytes that were in outputBuffer in the final onNext call.
byte[] finalBytes;
try {
outputBuffer = cipher.doFinal();
// Send the final bytes to the wrapped subscriber
wrappedSubscriber.onNext(ByteBuffer.wrap(outputBuffer));
finalBytes = cipher.doFinal();
} catch (final GeneralSecurityException exception) {
// Even if doFinal fails, downstream still expects to receive the bytes that were in outputBuffer
wrappedSubscriber.onNext(ByteBuffer.wrap(outputBuffer));
// Forward error, else the wrapped subscriber waits indefinitely
wrappedSubscriber.onError(exception);
throw new S3EncryptionClientSecurityException(exception.getMessage(), exception);
}
wrappedSubscriber.onComplete();

// Combine the bytes from outputBuffer and finalBytes into one onNext call.
// Downstream has requested one item in its request method, so this class can only call onNext once.
// This single onNext call must contain both the bytes from outputBuffer and the tag.
byte[] combinedBytes;
if (outputBuffer != null && outputBuffer.length > 0 && finalBytes != null && finalBytes.length > 0) {
combinedBytes = new byte[outputBuffer.length + finalBytes.length];
System.arraycopy(outputBuffer, 0, combinedBytes, 0, outputBuffer.length);
System.arraycopy(finalBytes, 0, combinedBytes, outputBuffer.length, finalBytes.length);
} else if (outputBuffer != null && outputBuffer.length > 0) {
combinedBytes = outputBuffer;
} else if (finalBytes != null && finalBytes.length > 0) {
combinedBytes = finalBytes;
} else {
combinedBytes = new byte[0];
}

wrappedSubscriber.onNext(ByteBuffer.wrap(combinedBytes));
}

}
Original file line number Diff line number Diff line change
Expand Up @@ -729,6 +729,8 @@ public void copyObjectTransparentlyAsync() {
* Test which artificially limits the size of buffers using {@link TinyBufferAsyncRequestBody}.
* This tests edge cases where network conditions result in buffers with length shorter than
* the cipher's block size.
* Note that TinyAsyncRequestBody is not fully spec-compliant, and will cause IllegalStateExceptions
* to be logged when debug logging is enabled.
* @throws IOException
*/
@Test
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -264,6 +264,7 @@ public void AsyncAesCbcV1toV3RangedGet(Object keyMaterial) {
assertEquals("klmnopqrst0", output);

// Valid start index within input and end index out of range, returns object from start index to End of Stream
// This causes a spurious NPE to be logged when debug logging is enabled.
objectResponse = v3Client.getObject(builder -> builder
.bucket(BUCKET)
.range("bytes=190-300")
Expand All @@ -288,6 +289,7 @@ public void AsyncAesCbcV1toV3RangedGet(Object keyMaterial) {
assertEquals(input, output);

// Invalid range starting index and ending index greater than object length but within Cipher Block size, returns empty object
// This causes a spurious NPE to be logged when debug logging is enabled.
objectResponse = v3Client.getObject(builder -> builder
.bucket(BUCKET)
.range("bytes=216-217")
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,9 @@
* AsyncRequestBody which wraps another AsyncRequestBody with a {@link TinyBufferSubscriber}.
* This is useful for testing poor network conditions where buffers may not be larger than
* the cipher's block size.
* DO NOT USE THIS IN PRODUCTION. In addition to degraded performance,
* it will cause IllegalStateExceptions in the base Subscriber as it does not comply
* with the Reactive Streaming spec.
*/
public class TinyBufferAsyncRequestBody implements AsyncRequestBody {

Expand Down