When you configure an HTTPS listener for a CLB instance, the TLS security policy determines which TLS protocol versions and cipher suites are used for TLS negotiation with clients. CLB provides several predefined TLS security policies.
How it works
A TLS security policy for CLB defines the supported TLS protocol versions and cipher suites for TLS negotiation. During the TLS handshake, the client sends a list of its supported protocol versions and cipher suites in a Client Hello message. Based on the policy, CLB selects a mutually supported protocol version and cipher suite combination from the client's list and responds with a Server Hello message. This combination determines subsequent steps, such as key exchange and session key generation.
TLS security policies
Security compliance standards may require your CLB instance to use a specific TLS security policy. The following table describes the TLS protocol versions and cipher suites supported by each policy to help you select one that meets your requirements. CLB does not support custom TLS security policies. If you need this functionality, use Application Load Balancer (ALB) or Network Load Balancer (NLB).
For Internet-facing applications without special compatibility requirements, we recommend using the tls_cipher_policy_1_2 policy or a stricter one.
Configure a TLS security policy
Console
When adding an HTTPS listener, click Modify next to Advanced Settings on the Certificate Management Service tab. In the expanded section, select a TLS Security Policy.
To modify a TLS security policy, go to the Listener tab on the instance details page and click the name of the target HTTPS listener to open the Listener Details dialog box. In the SSL Certificate section, modify the TLS Security Policy.
API
When calling CreateLoadBalancerHTTPSListener to create an HTTPS listener or SetLoadBalancerHTTPSListenerAttribute to modify one, specify the TLS security policy in the TLSCipherPolicy parameter.
Billing
TLS security policies are free. However, using CLB instances incurs fees.
FAQ
Custom TLS security policies on CLB
No. CLB supports only predefined TLS security policies.
If you need a custom TLS security policy, for example, to meet specific security compliance requirements, use one of the following products:
-
ALB: You can configure custom TLS security policies for HTTPS listeners.
-
NLB: You can configure custom TLS security policies for TCP/SSL listeners.
Why does my backend Nginx ssl_protocols configuration not take effect?
CLB terminates TLS connections. The TLS version visible to clients is determined by the CLB TLS security policy, not by the ssl_protocols directive on your backend servers. To change the supported TLS versions, modify the TLS security policy for the target HTTPS listener: on the Listener tab, click the HTTPS listener name to open the Listener Details dialog box, and change the TLS security policy in the SSL Certificate section.
Why does my browser still display a security warning even though CLB has a valid certificate bound?
Possible causes and troubleshooting suggestions are as follows:
-
Weak cipher suite in the TLS security policy: If the TLS security policy for your HTTPS listener is set to
tls_cipher_policy_1_0or another policy that includes weak cipher suites (such asDES-CBC3-SHA), browsers may display a security warning because these suites do not support Perfect Forward Secrecy (PFS). We recommend navigating to the instance details page, clicking the Listener tab, clicking the target HTTPS listener name to open the Listener Details dialog box, and changing the TLS Security Policy totls_cipher_policy_1_2_strictin the SSL Certificate section. -
Outdated forwarding rules or domain extensions: If your forwarding rules or domain extensions contain stale entries unrelated to the current access domain, certificate domain mismatch errors may occur. Remove any unnecessary forwarding rules from the listener.
-
Certificate domain mismatch or expired certificate: Verify that the server certificate bound to the listener covers the access domain and has not expired.
-
Browser cache: Clear your browser cache and retry.
We recommend troubleshooting in the order listed above.
How do I fix the CVE-2016-2183 vulnerability?
CVE-2016-2183 is an SSL/TLS information disclosure vulnerability known as the Sweet32 attack. The root cause is that the TLS security policy includes the DES-CBC3-SHA (3DES) cipher suite. The tls_cipher_policy_1_0, tls_cipher_policy_1_1, and tls_cipher_policy_1_2 policies all include this cipher suite.
To fix this vulnerability:
-
Log on to the CLB console and go to the target CLB instance.
-
On the Listener tab, click the name of the target HTTPS listener to open the Listener Details dialog box.
-
In the SSL Certificate section, change TLS Security Policy to
tls_cipher_policy_1_2_strictortls_cipher_policy_1_2_strict_with_1_3. -
Confirm and submit the change. After the change takes effect, the
DES-CBC3-SHAcipher suite is removed and CVE-2016-2183 is fixed.
We recommend performing this change during off-peak hours. If an issue occurs after the change, you can immediately roll back by modifying the listener configuration.
Production environment
-
TLS protocol version: If your application has no special compatibility requirements, use TLS 1.2 and TLS 1.3 for optimal security.
-
Rollback: If an issue occurs after you adjust the TLS security policy, you can immediately roll back the change by modifying the listener configuration. Perform these changes during off-peak hours.
-
Key exchange algorithm: Unless your application has specific compatibility requirements, avoid the following RSA-based cipher suites in a production environment:
AES128-GCM-SHA256,AES256-GCM-SHA384,AES128-SHA256,AES256-SHA256,AES128-SHA,AES256-SHA, andDES-CBC3-SHA. Because they do not support Perfect Forward Secrecy (PFS), these suites are vulnerable to side-channel attacks. Prioritize cipher suites that use ECDHE or DHE for key exchange. -
SSL Labs rating: If your SSL Labs test returns a grade of B and TLS 1.3 is not supported, select
tls_cipher_policy_1_2_strict_with_1_3to enable TLS 1.3 and achieve an A rating. CLB terminates TLS connections — the TLS version negotiated with clients is determined by the CLB TLS security policy, not by thessl_protocolsconfiguration on backend servers.The following table shows the SSL Labs rating associated with each policy:
TLS security policy
TLS 1.3 support
SSL Labs rating
tls_cipher_policy_1_0
No
B
tls_cipher_policy_1_1
No
B
tls_cipher_policy_1_2
No
B
tls_cipher_policy_1_2_strict
No
B
tls_cipher_policy_1_2_strict_with_1_3
Yes
A
Security recommendations
tls_cipher_policy_1_0, tls_cipher_policy_1_1, and tls_cipher_policy_1_2 include the DES-CBC3-SHA cipher suite (IANA name: 3DES_EDE_CBC_SHA). This suite uses a 64-bit block cipher and is vulnerable to the Sweet32 attack (CVE-2016-2183). Upgrade your TLS security policy to tls_cipher_policy_1_2_strict or later to eliminate this risk.
|
Policy |
Includes DES-CBC3-SHA |
Recommendation |
|
tls_cipher_policy_1_0 |
Yes |
Upgrade required — Sweet32 risk (CVE-2016-2183) |
|
tls_cipher_policy_1_1 |
Yes |
Upgrade required — Sweet32 risk (CVE-2016-2183) |
|
tls_cipher_policy_1_2 |
Yes |
Upgrade required — Sweet32 risk (CVE-2016-2183) |
|
tls_cipher_policy_1_2_strict |
No |
Safe |
|
tls_cipher_policy_1_2_strict_with_1_3 |
No |
Safe |
Upgrade using the console
-
Log on to the CLB console and go to the target instance.
-
On the Listener tab, click the name of the target HTTPS listener to open the Listener Details dialog box.
-
In the SSL Certificate section, change TLS Security Policy to
tls_cipher_policy_1_2_strict. -
Confirm and submit the change.
Upgrade using the API
Call SetLoadBalancerHTTPSListenerAttribute and set TLSCipherPolicy to tls_cipher_policy_1_2_strict.
Compatibility considerations
Upgrading to tls_cipher_policy_1_2_strict removes support for TLS 1.0, TLS 1.1, and legacy cipher suites including DES-CBC3-SHA. Before upgrading:
-
Verify that your clients support TLS 1.2.
-
Perform the change during off-peak hours to minimize business impact.
TLS cipher suite mapping
This table provides the mapping between the OpenSSL format, IANA standard format, and hexadecimal representation of TLS cipher suites.