Getting Started Guide for HTTPS Forwarding Configuration

CLB Capability Description

The CLB has achieved a significant improvement in HTTPS performance through deep optimization of the protocol stack and server. At the same time, we have greatly reduced the cost of certificates through international cooperation on certificates. CLB can bring significant benefits to the business in the following aspects:

1. Using HTTPS does not slow down client access.
2. The SSL encryption and decryption performance of a single server in the cluster is up to 65,000 cps for a full handshake. Compared with high-performance CPUs, it has been improved by at least 3.5 times, saving server costs, greatly improving business operations and service capabilities during sudden traffic increases, and enhancing computing-based anti-attack capabilities.
3. Supports multiple protocol offloading and conversion. Reduce the pressure on the business to adapt to various client protocols. The business backend only needs to support HTTP1.1 to use various versions of protocols such as HTTP2, SPDY, SSL3.0 and TLS1.2.
4. One-stop SSL certificate application, monitoring, and replacement. We have started dialogues with international certificate vendors Comodo and Symantec to explore cooperation and significantly reduce the certificate application process and costs.
5. Anti-CC and WAF features. It can effectively prevent slow connections, high-frequency targeted attacks, SQL injections, web page Trojans and other application layer attacks.

HTTP, HTTPS Header Identifier

CLB proxies HTTPS. Whether it is an HTTP or HTTPS request, when CLB forwards it to the backend CVM, it is an HTTP request. At this time, developers cannot tell whether the front-end request is HTTP or HTTPS.

When CLB forwards the request to the backend CVM, the header will be embedded with X-Client-Proto:

X-Client-Proto: http (front-end is HTTP request)
X-Client-Proto: https (front-end is HTTPS request)

Getting Started

Assume that the user needs to configure the website https://example.com. Developers want users to type www.example.com directly when they enter a URL in a browser. It can be accessed securely via HTTPS protocol.

At this time, the www.example.com request forwarding process entered by the user is as follows:

1. The request is transmitted via HTTP protocol, accesses port 80 of the CLB listener through VIP, and is forwarded to port 8080 of the backend CVM.
2. By configuring the rewrite operation on the backend server's Nginx, the request goes through port 8080 and is rewritten to https://example.com page.
3. At this time, the browser sends https://example.com again to the corresponding HTTPS zone. The request accesses port 443 of the CLB listener through VIP and is forwarded to port 80 of the backend CVM.
   At this point, the request forwarding is completed.

This operation rewrites the user's HTTP request into a more secure HTTPS request without the browser user's awareness. To implement the above request forwarding operation, users can configure the backend server as follows:

server {

    listen 8080; 
    server_name www.example.com;

    location / {

        #! customized_conf_begin;
        client_max_body_size 200m;
        rewrite ^/.(.*) https://$host/$1 redirect;

} 
}

Alternatively, in the new version of Nginx, redirect the Nginx HTTP page to the HTTPS page by using the recommended 301 redirection method:

server {     
      listen      80;
      server_name    www.example.com;
      return      301 https://$server_name$request_uri;
}

server {
      listen      443 ssl;
     server_name    www.example.com;
    [....]
}