Description of Change
At Zuora, the security and trust of our customers are of utmost importance to us. We are dedicated to safeguarding your data and continually enhancing our security measures. In line with this commitment, we are implementing important infrastructure changes to support the latest data transport standards while deprecating older encryption protocols and cipher suites. These changes are aimed at maintaining alignment with industry best practices for enhanced security. Please refer to the schedule below for the upcoming changes we will be making.
Scope of Change
Three items are included in this change:
- Implementing support for the TLS 1.3, and continued support for TLS 1.2 SSL Protocols
- Introducing three additional strong ciphers to enhance security.
- Phasing out support for two older cipher suites.
Impact of Change
The upcoming changes will have the following impacts:
- All API and UI traffic for all Zuora Billing environments will be impacted
Data Center and Environment Details
Change details per environment and data center are as follows:
Please note that the cipher suites being deprecated are exclusive to Americas Cloud 2 (NA2). These cipher suites are not utilized in other environments such as NA1 and EU.
Change Schedule by Environment
The schedule for these changes and the impacted environments are as follows:
- October 21, 2023:
-
May 18, 2024:
Technical Details
Ciphers being deprecated (removed) from Americas Cloud 2 (NA2) only, All Environments
OpenSSL/AWS name
|
Equivalent RFC name
|
ECDHE-RSA-AES128-SHA
|
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
|
ECDHE-RSA-AES256-SHA
|
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
|
Ciphers supported following above changes (All Environments)
OpenSSL/AWS name
|
Equivalent RFC name
|
TLS-AES-128-GCM-SHA256
|
TLS_AES_128_GCM_SHA256
|
TLS-AES-256-GCM-SHA384
|
TLS_AES_256_GCM_SHA384
|
TLS-CHACHA20-POLY1305-SHA256
|
TLS_CHACHA20_POLY1305_SHA256
|
ECDHE-RSA-AES128-GCM-SHA256
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
|
ECDHE-RSA-AES128-SHA256
|
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
|
ECDHE-RSA-AES256-GCM-SHA384
|
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
|
ECDHE-RSA-AES256-SHA384
|
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
|
Highlighted are newly introduced TLS 1.3 ciphers
FAQs
What is the reason behind Zuora's continued support for 128-bit CBC ciphers?
Zoura continues to offer support for two specific 128-bit CBC ciphers, recognizing that some customers heavily rely on these ciphers for their API integrations. Although we are aware of the significance of employing strong cipher suites, we understand that certain customers have constraints and dependencies related to these particular ciphers.
Does Zuora's support for the two CBC ciphers pose a security risk?
Zuora continues to maintain the highest security ratings (A+) using standard measuring tools such as SSLLabs for the ciphers presently supported and 'to-be' supported following the above changes.
To understand the security risks of supporting these two CBC ciphers, it is important to understand how TLS works and the role Zuora's customers play in the connection process. During the initial TLS handshake, the client (customer) determines the strongest common cipher suite to be used in the transaction. The client achieves this by sending a ClientHello message to the server, which includes various details:
- Supported TLS Versions: The ClientHello message lists the TLS versions supported by the client, enabling the server to select the highest compatible version for the session.
- Cipher Suite Preferences: The client includes a prioritized list of cipher suites it supports, indicating the encryption algorithms and key exchange methods it prefers. The server selects the most appropriate cipher suite from this list based on its own capabilities and configuration. Zuora supports strong ciphers and recommends that all customers connect to our API's using only strong ciphers.
- Random Number Generation: The client generates a random number known as the "client random" and includes it in the ClientHello message. This random value adds entropy to the key generation process and ensures uniqueness in session keys.
- Supported Extensions: The ClientHello message may also contain optional extensions that provide additional features or security enhancements. Common extensions include Server Name Indication (SNI), which specifies the intended server hostname, and Extended Validation (EV), which offers extra validation for SSL certificates.
By exchanging the ClientHello and ServerHello messages, the client and server negotiate and agree upon the most secure TLS version, cipher suite, and other parameters for the session. This ensures a secure and mutually agreed-upon configuration for the transaction while leveraging the strongest common cipher suite supported by the client's integration.
To mitigate the potential risks associated with weak ciphers, it is crucial for customers relying on the two supported CBC ciphers to take proactive measures. Zuora strongly recommends the following actions:
- Upgrade Client-Side Software: Customers should prioritize upgrading their client-side software used to connect to Zuora's APIs. By using updated software versions, clients can ensure compatibility with stronger cipher suites and mitigate the vulnerabilities associated with weak ciphers.
- Implement Strong Security Practices: It is essential to establish robust security practices across multiple layers of the system. This includes enforcing stringent access controls, implementing strong authentication mechanisms, regularly updating software and systems, and employing secure key management practices. By adopting these practices, customers can enhance the overall security of their communication channels.
By upgrading client-side software and implementing comprehensive security practices, customers can minimize the risk of weak cipher exploitation and maintain the integrity and confidentiality of their communications when interacting with Zuora's APIs.
How can I test and determine which cipher suites my integration supports?
Work with your internal integration support or Engineering teams to determine which cipher suites are supported by your integration.
Review integration documentation to determine cipher compatibility and support
Test and Validate your integrations once the API Sandbox changes have been made