Support for Custom OpenSSL Ciphers in Ceph RGW #1005
Description
Currently, Ceph RGW (RADOS Gateway) supports a limited set of hardcoded OpenSSL ciphers, such as AES-256-CBC and AES-256-ECB, for encryption and decryption operations. This limitation restricts the ability to use other OpenSSL-supported ciphers, which could be beneficial for specific use cases or compliance requirements.
Benefits:
- Flexibility: Users can configure and use any OpenSSL-supported cipher, including custom or hardware-accelerated ciphers.
- Compliance: Organizations with specific encryption requirements (e.g., regulatory compliance) can use ciphers that meet their needs.
- Future-Proofing: As encryption standards evolve, new ciphers can be added without requiring significant code changes.
We suggest moving from a hardcoded check to a pass-through model using the OpenSSL EVP_get_cipherbyname() interface. To maintain Ceph's security standards, this could be gated behind a new configuration parameter: rgw_crypt_allowed_ciphers.
If a requested cipher is in the allowed list, RGW fetches it via the EVP layer.
If the list is empty or the cipher is not found, it defaults to the existing AES-256-CBC behavior.
Contribution
We are interested in contributing this feature and are prepared to submit a Pull Request (PR) for this refactor.
Before we commit engineering resources, we would like to ask the maintainers:
- Is a PR that enables cipher flexibility via a validated pass-through model conceptually acceptable to the RGW leadership?
- Are there specific architectural concerns regarding the S3/Swift API compatibility that we should address in the initial design of the PR?
- If we ensure that the default behavior remains unchanged and security is managed via an explicit whitelist, would the community be open to merging this contribution?