You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2021/04/02 01:37:00 UTC

[jira] [Closed] (JAMES-3524) Re-enable AES encryption for the BlobStore

     [ https://issues.apache.org/jira/browse/JAMES-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier closed JAMES-3524.
---------------------------------
    Fix Version/s: 3.6.0
       Resolution: Fixed

https://github.com/apache/james-project/pull/342 solved this

> Re-enable AES encryption for the BlobStore
> ------------------------------------------
>
>                 Key: JAMES-3524
>                 URL: https://issues.apache.org/jira/browse/JAMES-3524
>             Project: James Server
>          Issue Type: Task
>          Components: Blob
>    Affects Versions: 3.6.0
>            Reporter: Benoit Tellier
>            Priority: Major
>              Labels: security
>             Fix For: 3.6.0
>
>          Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> Users might not wish to administrate themselves a S3 compatible blobStore and might rely on a third arty to do so. As such, in order to avoid a third party compromission to escalate to a data leak, a good practice is to encrypt the data symmetrically, the secret key generation secrets being stored on the appkication server.
> Such a mechanism prevents data leak for a third party compromission, but do not deend against an application server compromission (as the attacker would then know the private key).
> As part of his work on a Swift compatible blob store [1] , Jean Helou contributed an AES encryption mechanism for that very blob store [2]. However, changes in the blobStore design, dropping of the (non-reactive) JCloud driver, rewrite on top of S3 API, as well as modularization of the blobStore (extraction of the BlobStoreDAO, PassThough VS Deduplicating blobStore) [3] lead to this work being dropped, for the sake of simplicity in an effort to finish a long lasting refactoring.
> Note that:
> - Needs to encrypt blob payload had been requested on top of the Cassandra blob store [4] in order to prevents (full) data leaks from a Cassandra DB compromission.
>  - Some optimizations (prior [3]) of the object storage when using S3 were incompatible with payload encryption [5]
> By adoption design proposed in [3], reusing the job made by Jean in [2] we can write a generic AESBlobStoreDAO that wraps any other BlobStoreDAO, adding a security layer. Using the BlobStoreChooser, we then can re-enable this capability on top of the Distributed James server.
> [1] https://issues.apache.org/jira/browse/JAMES-2525
> [2] https://github.com/linagora/james-project/pull/1865 & https://github.com/linagora/james-project/pull/1975 & https://issues.apache.org/jira/browse/JAMES-2589
> [3] https://issues.apache.org/jira/browse/JAMES-3028
> [4] https://issues.apache.org/jira/browse/JAMES-3023
> [5] https://issues.apache.org/jira/browse/JAMES-2692



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org