FAQ about HTTPS acceleration configuration and usage-CDN(CDN)-阿里云帮助中心

HTTPS is an HTTP channel designed for security, providing better protection for content transmission over CDN. While accessing content at high speed, clients can browse website content more safely and effectively. This topic provides answers to frequently asked questions about HTTPS.

HTTPS basics and principles

What are the common types of HTTP attacks?

The following are common types of HTTP attacks:

SQL injection: Attackers exploit existing applications to inject malicious SQL commands into backend database engines for execution. They can also enter malicious SQL statements in web forms to obtain the database of a website that has security vulnerabilities, instead of executing SQL statements as intended by the designer.
Cross-site scripting: Cross-site scripting (XSS) is one of the most common and basic methods to attack websites. Attackers publish data that contains malicious code on web pages. When a user views such a web page, the specific script runs with the identity and permissions of the browsing user. XSS makes it relatively easy to tamper with user data and steal user information.
Cross-site request forgery: Cross-site request forgery (CSRF) is another common attack. Attackers forge requests in various ways to mimic the behavior of users submitting forms, in order to tamper with user data or perform specific tasks. To impersonate a user, CSRF attacks and XSS attacks usually work together, but attackers can also use other means, for example, tricking users into clicking a malicious link.
HTTP headers attack: When you use a browser to view any website, regardless of the technologies and frameworks used, the HTTP protocol is involved. In the HTTP protocol, there is a blank line between the response header and the content, that is, two sets of CRLF (0x0D 0x0A) characters. This blank line marks the end of the headers and the start of the content, and attackers can exploit this. As long as attackers can find a way to inject arbitrary characters into the headers, this attack can happen.
Redirection attack: A commonly used attack is phishing. Phishing attackers usually send victims a legitimate-looking link. When victims visit the link, they are redirected to a malicious website, so that the attackers gain their trust and steal their information. To prevent this, all redirection operations must be validated to avoid redirecting to dangerous destinations. A common solution is a whitelist: add legitimate redirection URLs to the whitelist and reject redirections to domains that are not on the whitelist. A second solution is redirection tokens: append a token to legitimate URLs and validate the token upon redirection.

Does enabling HTTPS acceleration consume more resources or slow down access?

When HTTPS is enabled on the origin, computing resource consumption increases compared with HTTP access to the origin. The increase mainly comes from asymmetric encryption and decryption during the HTTPS handshake, and resource consumption grows significantly under high concurrency. The consumption of symmetric encryption and decryption is basically the same as HTTP, so the session reuse rate should be increased. However, accessing the origin directly over HTTPS takes longer than accessing the origin directly over HTTP. For static content, edge distribution reduces transmission time at the cost of extra handshake time, so overall access time decreases. In addition, static resources do not need to be fetched from the origin, which reduces interactions with the origin and lowers resource consumption on the origin.

HTTPS usage scenarios and decisions

Is HTTPS required only for site logon?

No. You need to analyze this from the following aspects:

Security: If some pages are HTTP and some pages are HTTPS, when other resources (such as JS or CSS files) are loaded over HTTP or through an insecure CDN service, the website still faces the risk of exposing user information. Site-wide HTTPS is the simplest way to prevent this risk.
Performance: When a website supports both HTTPS and HTTP, switching between the two protocols requires many server-side redirects, and when these redirects are triggered, page loading slows down.
Web ecosystem: Browsers support HTTPS more favorably, and search engines provide better indexing support for HTTPS sites.

HTTPS is already configured on the origin. Do I still need to configure HTTPS on CDN?

HTTPS is the interaction between the client and the server. Before CDN is used, the client interacts directly with the origin, so HTTPS must be configured on the origin. After CDN is used, the client interacts with CDN. If you want to access CDN over HTTPS, you must configure an HTTPS certificate on CDN. For information about how to configure an HTTPS certificate on CDN, see Configure an HTTPS certificate.

The HTTPS certificate on the origin has been updated. Does the certificate on CDN need to be updated accordingly?

No. The HTTPS certificate on the origin server and the HTTPS certificate on CDN exist independently of each other. Updating the certificate on the origin does not affect the HTTPS certificate on CDN. You need to update the HTTPS certificate on CDN only when the certificate configured on CDN is about to expire or has already expired. For more information, see Configure an HTTPS certificate.

Does the origin port change after an HTTPS certificate is configured?

Configuring an HTTPS certificate for an accelerated domain name does not directly affect the origin port, but it indirectly affects the origin port in protocol follow mode. The specific rules are as follows:

1. Configuring an HTTPS certificate itself has nothing to do with the origin port

The HTTPS certificate only provides encryption between the client and CDN nodes. It does not change the origin protocol or port between CDN and the origin. Origin behavior is independently controlled by the origin protocol setting: when it is set to HTTP, CDN fetches content from the origin over port 80 by default; when it is set to HTTPS, CDN fetches content from the origin over port 443 by default. This is unrelated to whether a certificate is configured on the edge.

2. When the origin protocol is set to follow, it is affected by the client access protocol

After an HTTPS certificate is configured and HTTPS secure acceleration is enabled, CDN supports access over both HTTP and HTTPS;
If the origin protocol is set to follow the client: when the client accesses CDN over HTTP, CDN fetches content from the origin over port 80; when the client accesses CDN over HTTPS, CDN fetches content from the origin over port 443.

3. If full-link HTTPS encryption is required

Configuring only an edge certificate is not enough. You must also set the origin protocol to HTTPS in the origin settings, and make sure that the origin supports HTTPS access.

For information about how to configure the origin protocol, see Configure the origin protocol policy.

Certificate configuration and upload

When uploading a third-party certificate that contains multiple .crt files, how do I upload the certificate?

Certificate files issued by an intermediate certificate authority contain multiple certificates. You must concatenate the server certificate and the intermediate certificates into one complete certificate before uploading.

Open all certificate files in the *.PEM format with a text editor. Place the server certificate first, followed by the intermediate certificates. There must be no blank lines between the certificates. In most cases, the certificate authority provides corresponding instructions when issuing the certificate. Follow the instructions.

The concatenated certificate is as follows.

HTTPS access behavior and compatibility

When configuring HSTS, after enabling include subdomains, do I need to enable HSTS on the subdomains?

You do not need to enable HSTS on the subdomains. After you enable Include Subdomains, the HSTS policy takes effect on all subdomains. Make sure that each subdomain supports normal HTTPS access. Otherwise, the subdomain will become inaccessible.

HTTPS is already configured. Why do clients still access the site over HTTP?

Whether a client accesses the site over HTTP or HTTPS is entirely the client's behavior. If you want clients to be forced to use HTTPS access, you can enable force HTTPS redirect on CDN. For more information, see Configure HTTP/S redirection.

Why can most devices access a domain name accelerated over HTTPS, while some devices cannot?

This is mainly because CDN relies on SNI when processing HTTPS requests. SNI is an extension to the TLS protocol that allows a client to specify the hostname it wants to visit when initiating an HTTPS connection request.

However, some older or specially configured clients (for example, old versions of Android or iOS, Java 6 and earlier, and some IoT devices) may not support SNI, or may not send SNI information when initiating HTTPS requests. In this case, CDN nodes cannot determine the exact site the client wants to visit and therefore cannot provide the correct SSL/TLS certificate. As a result, the HTTPS connection attempt fails, and users cannot access the website content.

To improve this situation, we recommend the following measures:

Upgrade the client system: Make sure the operating systems and software in use are up to date so that SNI is supported.
Update IoT device firmware: For IoT devices, regularly check for and install the latest firmware updates provided by the manufacturer.

HTTPS billing

Are there extra charges after enabling HTTPS acceleration on CDN?

Yes. Enabling HTTPS acceleration on CDN actually enables HTTPS on the link between the client and CDN edge nodes. Because SSL handshake and content decryption both require computation, the CPU resource consumption of CDN servers increases. However, resource consumption on your origin server does not increase, because the link between CDN edge nodes and your origin still uses the HTTP protocol and does not add extra load to your origin.

If you purchase different types of certificates, extra fees are required. You can also log on to the Certificate Management Service console to apply for a test certificate (free edition), which is a DV-level certificate. You can apply for one test certificate for each accelerated domain name. The certificate is valid for three months and can be automatically renewed for free. After configuring an HTTPS certificate, CDN bills all HTTPS requests for that domain name. For information about charges for static HTTPS requests, see Billing of HTTPS requests for static content.

When requests hit the IP blacklist or User-Agent blacklist, or when requests return 403/404, are HTTPS requests billed?

HTTPS requests are billed. When a request hits certain policy rules and returns a 403 or 404 status code, the request is correctly responded to, so it is counted as one HTTPS request. Because such a request does not carry any resource content, the billed traffic is very small.