SSE-C objects expose plaintext MD5 as ETag, allowing content recovery with only s3:ListBucket

Summary

A user with only s3:ListBucket permission, without s3:GetObject and without the customer key, can recover the plaintext of low-entropy SSE-C objects in seconds.

When an object is stored with SSE-C (server-side encryption with customer-provided keys), RustFS stores and returns the MD5 of the plaintext as the object's ETag. The ETag is persisted unencrypted in object metadata and returned by list operations that do not require the customer key. Anyone with s3:ListBucket on the bucket, or read access to the underlying drives or backups, can therefore:

1. confirm guesses of an encrypted object's content, by comparing MD5(candidate) with the ETag;
2. brute-force low-entropy content (templated documents, amounts, IDs, yes/no values);
3. determine that two objects encrypted under different customer keys have identical content.

This breaks the confidentiality guarantee SSE-C is meant to provide against parties who do not hold the key. MinIO, which RustFS aims to be compatible with, avoids this by sealing the ETag with the per-object encryption key, so identical uploads produce different ETags.

Details

This issue surfaced when we tried to replace MinIO with RustFS in our CI pipeline. A test that asserted non-equal ETag for SSE-C objects failed.

NOTE: I used Claude AI to research the details in this section. All other sections are written and/or verified by a me.

Analysis done against commit 36c6c2e34be75856fa900f5b30e16b288803b70f.

**1. The ETag…