The "active" strategy outlined here seems to be pretty strange. The attacker's data needs to be combined into the unencrypted data being sent via S3, so I guess it has compromised the S3 client environment or dataset already in some way? I'm not sure if that qualifies as a direct attack on compression+encryption in the S3 service. In general, it seems like whether to compress+encrypt should be a policy decision, not something arbitrarily chosen by the S3 implementation (as this article claims minio does). Matt On Wed, Jul 5, 2023 at 10:24 AM Casey Bodley <cbodley@redhat.com> wrote:
thanks Josh, i wasn't aware of attacks in this space. a naive search came up with a blog post from minio about a 'compression-ratio side channel' at https://blog.min.io/c-e-compression-encryption/. is that the same kind of issue you're concerned about here?
without more time to evaluate this, i'm tempted to disable the feature for reef
On Tue, Jul 4, 2023 at 3:13 AM Josh Salomon <jsalomon@redhat.com> wrote:
Please note that compression before encryption is considered a security
breach. I would not implement this without a clear warning and specific user approval.
Regards,
Josh
On Mon, Jul 3, 2023 at 10:54 PM Casey Bodley <cbodley@redhat.com> wrote:
i opened https://github.com/ceph/ceph/pull/52300 to require a 'compress-encrypted' zonegroup feature for this, and updated the documentation and release note accordingly
On Mon, Jul 3, 2023 at 2:11 PM Casey Bodley <cbodley@redhat.com> wrote:
hey Shilpa and team,
early in the reef cycle, https://github.com/ceph/ceph/pull/46188 was contributed to support the combination of server-side compression and encryption on the same object data. only recently did we catch a regression in multisite, where such objects fail to replicate and can cause crashes. this bug, tracked in https://tracker.ceph.com/issues/57905, was just fixed and backported for reef in https://github.com/ceph/ceph/pull/52297. this was a regression in reef, so i was planning to treat it as a blocker
in that backport, i added a warning to the original release note:
RGW: Compression is now supported for objects uploaded with Server-Side Encryption. When both are enabled, compression is applied before encryption. WARNING: In a multisite configuration, objects that are both compressed and encrypted will not replicate correctly to Pacific or Quincy. Upgrade all zones to Reef before enabling compression.
it occurs to me that we might add a new 'compress-encrypted' feature flag to the zonegroup (similar to the 'resharding' flag in reef) to prevent this combination of compression+encryption until all zones upgrade and enable it. do you think that's worth doing, or is a release note sufficient?
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309