Client applications and OSS communicate securely using the transport layer security (TLS) protocol, which ensures privacy and data integrity over the Internet. You can specify a TLS version on an OSS server to ensure that clients adhere to the required security standards for communication links.
Prerequisites
RAM users must have permissions oss:PutTLSVersion
and oss:GetTLSVersion
. For detailed operations, see grant custom policy to RAM users.
TLS version description
TLS supports four versions: 1.0, 1.1, 1.2, and 1.3. The usage scenarios and browser support for each version are outlined below:
Protocol | Description | Scenarios | Supported mainstream browsers |
TLS 1.0 | The main encryption algorithms that are used include RSA, DES, and 3DES. TLS 1.0 has specific security vulnerabilities and is vulnerable to various attacks, such as BEAST and POODLE attacks. TLS 1.0 cannot ensure strong security for network connections and does not meet the compliance requirements of Payment Card Industry Data Security Standard (PCI DSS). | Because of security vulnerabilities, TLS 1.0 is no longer recommended for network protection. In most cases, we recommend that you update TLS 1.0 to a secure version at the earliest opportunity. |
|
TLS 1.1 | TLS 1.1 improves security for network connections, fixes some known vulnerabilities, and supports more powerful encryption algorithms, such as AES, RSA, and SHA-256. | TLS 1.1 is suitable for environments that require a relatively high level of security but do not require the latest TLS features. |
|
TLS 1.2 | TLS 1.2 further enhances security for network connections, and launches new features, such as Server Name Indication (SNI) and handshake protocols. TLS 1.2 supports more encryption algorithms, including AES-GCM, AES-CBC, and ECDHE. | TLS 1.2 is suitable for most common secure communication scenarios, including web applications, e-commerce websites, emails, and virtual private networks (VPNs). |
|
TLS 1.3 | TLS 1.3 significantly improves security, performance, and privacy. TLS 1.3 no longer supports some insecure encryption algorithms. It supports more powerful key exchange algorithms and encryption algorithms that reduce the delay of the handshake process, and also provides better forward secrecy and authentication mechanisms. | TLS 1.3 is suitable for scenarios in which high security, better performance, and privacy protection are required, such as in financial institutions, large Internet companies, and government agencies. |
|
Precautions
It is recommended to avoid setting the allowed TLS version to only TLS 1.0 or TLS 1.1 for a bucket. Including at least TLS 1.2 is advisable.
OSS defaults to TLS 1.2 as it is the mainstream version. Excluding TLS 1.2 may prevent access by some mainstream clients.
Downgrading the TLS version or disabling TLS version management can lead to security and compliance issues. Exercise caution when performing these operations.
Ensure that clients are not solely dependent on the TLS version you intend to disable before proceeding with the deactivation.
Procedures
Use the OSS console
Use the command line tool ossutil
Related API operations
For advanced customization, you can call RESTful APIs directly. This requires including signature calculations in your code. For more information, refer to PutBucketHttpsConfig and GetBucketHttpsConfig.
FAQ
How to determine the current TLS version?
To identify the TLS version used between a client and server when not specified by the client, run the following command:
openssl s_client -connect <Bucket>.<Endpoint>:443 -servername <Bucket>.<Endpoint>
The parameters in the command are described in the table below:
Parameter | Description |
Bucket | The name of the OSS bucket. |
Endpoint | The public endpoint, internal endpoint, or custom domain name of the bucket. |
The TLS version can be determined from the response.
How to determine whether the TLS version is configured successfully?
When the allowed TLS version is set to TLS 1.2 for a bucket, the following scenarios may occur:
Clients specifying TLS 1.2 can successfully access the server using the command below:
openssl s_client -connect <Bucket>.<Endpoint>:443 -servername <Bucket>.<Endpoint> -tls1_2
The parameters in the command are detailed in the following table:
Parameter
Description
Bucket
The name of the OSS bucket.
Endpoint
The public endpoint, internal endpoint, or custom domain name of the bucket.
A sample response to the command is shown below:
If the client does not specify a TLS version but supports TLS 1.2, access is successful using the following command:
openssl s_client -connect <Bucket>.<Endpoint>:443 -servername <Bucket>.<Endpoint>
A sample response is provided below:
If a client specifies a TLS version other than TLS 1.2, such as TLS 1.1, server access will fail as shown in the command below:
openssl s_client -connect <Bucket>.<Endpoint>:443 -servername <Bucket>.<Endpoint> -tls1_1
A sample response is as follows: