How to build a secure HTTPS site step by step

[[261093]]

Usually a web site opens HTTPS. Taking nginx as an example, we can configure it like this:

 server {
 listen 443 ssl http2;
 server_name www.example.com;
 index   index .html index .htm;
 root /www/www;
 ssl on ;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_certificate /usr/ local /nginx/ssl/example.com.rsa.cer;
 ssl_certificate_key /usr/ local /nginx/ssl/example.com.rsa.key ;
 ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;;
 }

The above nginx configuration includes configuring the listening port, enabling SSL, configuring the certificate, and supporting encryption algorithms. Generally speaking, users cannot directly enter https://www.example.com in the browser address bar to access the domain name, but enter the domain name. By default, it is accessed through the HTTP protocol, that is, http://www.example.com. Therefore, in the nginx configuration, we also need to define a server segment to handle HTTP access.

 server {
 listen 80 default_server;
 server_name_www.example.com;
 location / {
 return 302 https://$host$request_uri;
 }
 }

The above configuration listens to port 80 and defines a location to redirect HTTP requests 302 to the HTTPS host. This allows users to redirect to HTTPS no matter how they access the site.

But the problem is that this configuration is actually flawed. If the user manually enters the HTTP address from the browser, or clicks the HTTP link of the website from other places, the browser will rely on the server's 301/302 jump to use the HTTPS service. The first HTTP request may be hijacked because the data transmission in the middle is in plain text, which may cause the request to fail to reach the server, thus constituting HTTPS downgrade hijacking.

To solve downgrade hijacking, we can use HSTS.

What is HSTS?

HSTS (HTTP Strict Transport Security) is a set of Internet security policy mechanisms released by the Internet Engineering Task Force. Websites can configure HSTS to force browsers to use HTTPS to communicate with the website, making the website more secure.

The role of HSTS is to force the client (such as a browser) to use HTTPS to establish a connection with the server. The way for the server to enable HSTS is to include the `Strict-Transport-Security` field in the Hypertext Transfer Protocol response header returned by the server when the client makes a request via HTTPS. The `HSTS` field set during non-encrypted transmission is invalid.

For example, the response header of `https://example.com/` contains `Strict-Transport-Security: max-age=31536000; includeSubDomains`. This means two things:

In the next year (31536000 seconds), whenever a browser sends an HTTP request to example.com or its subdomains, it must use HTTPS to initiate the connection. For example, when a user clicks a hyperlink or enters http://www.example.com/ in the address bar, the browser should automatically convert http to https and then send a request directly to https://www.example.com/.

For the next year, users will no longer be able to ignore browser warnings and continue to visit example.com if the server sends an invalid TLS certificate.

How to configure?

Taking nginx as an example, we add a response header to the vhost of the corresponding domain name:

 server {
 ....
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" ;
 ...
 }

Parameter explanation:

• max-age, in seconds, tells the browser that within a specified time, this website must be accessed via the HTTPS protocol. That is, for the HTTP address of this website, the browser needs to replace it with HTTPS locally before sending a request.
• includeSubDomains, an optional parameter. If this parameter is specified, it indicates that all subdomains of this website must also be accessed through the HTTPS protocol.
• preload, optional parameter, HSTS response header can only be used for HTTPS response; the website must use the default port 443; the domain name must be used, not the IP. And after HSTS is enabled, once the website certificate is wrong, the user cannot choose to ignore it.

After the browser requests, the response header will show:

 strict-transport-security: max -age=31536000

As shown in the figure:

HSTS can effectively solve the HTTPS downgrade attack, but the first HTTP request before HSTS takes effect cannot be avoided from being hijacked. In order to solve this problem, browser manufacturers have proposed the HSTS Preload List solution: a built-in list that can be updated regularly, and for domain names in the list, the HTTPS protocol will be used even if the user has not visited it before.

Currently, this Preload List is maintained by Google Chrome and is used by Chrome, Firefox, Safari, IE 11 and Microsoft Edge. If you want to add your domain name to this list, you must first meet the following conditions:

• Have a valid certificate (if using a SHA-1 certificate, the expiration date must be before 2016);
• Redirect all HTTP traffic to HTTPS;
• Make sure HTTPS is enabled on all subdomains;
• Output HSTS response header:
• max-age cannot be less than 18 weeks (10886400 seconds);
• The includeSubdomains parameter must be specified;
• The preload parameter must be specified;

However, even if all the above conditions are met, it may not necessarily be included in the HSTS Preload List. For more information, see here (https://hstspreload.org/). Through Chrome's chrome://net-internals/#hsts tool, you can check whether a website is in the Preload List, and you can also manually add a domain name to the local Preload List.

My suggestion for HSTS and HSTS Preload List is that you should not enable them unless you can ensure that you will always provide HTTPS services. Because once HSTS takes effect, if you want to redirect the website to HTTP, the old users will be redirected infinitely, and the only way is to change the domain name.

If you are sure you want to enable it, click https://hstspreload.org, enter your domain name, check the protocol, and submit.

Once confirmed, you can submit your domain to the HSTS preload list:

After successful submission, a success message will be returned to you, but you must ensure that your configuration is always enabled, otherwise it will be deleted from the list.

Visit again and check the browser response header:

In addition, to make HTTPS websites more secure and faster, we should also do the following:

First, the key must be complex enough. For example, for an RSA key pair, it is best to have more than 2048 bits.

Second, the reasonable configuration of ssl_ciphers, try to abandon those encryption algorithms that have been proven to be insecure, and use newer algorithms that have been proven to have no security threats. For example, you can configure it like this:

 ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH +ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS- CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EEC DH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES;

Third, avoid using encryption protocols that have been proven to be insecure, such as SSLV2 and SSLV3, and use TLSv1.2 TLSv1.3 instead;

 ssl_protocols TLSv1.2 TLSv1.3;

Generally speaking, newer protocols are optimized for the previous version. For example, TLS1.2 and TLS1.3 protocols. You can look at the encryption process of these two protocols. First, let's look at the encryption process of TLS1.2:

Taking the ECDHE key exchange algorithm as an example, the complete SSL handshake process of the TLS1.2 protocol is as follows:

• In the first step, the client sends a ClientHello message, which mainly includes the protocol version supported by the client, the encryption suite list, and the ECC extension information required for the handshake process;
• In the second step, the server responds with a ServerHello message containing the selected cipher suite and ECC extensions; sends the certificate to the client; generates an ECDH temporary public key using the parameters provided by the client, and responds with a ServerKeyExchange message;
• In the third step, after the client receives ServerKeyExchange, it uses the certificate public key to verify the signature, obtains the server's ECDH temporary public key, and generates the shared key required for the session; generates an ECDH temporary public key and a ClientKeyExchange message and sends them to the server;
• Step 4: The server processes the ClientKeyExchange message and obtains the client's ECDH temporary public key; the server generates the shared key required for the session; and sends a key negotiation completion message to the client;
• In the fifth step, both parties use the generated shared key to encrypt the message for transmission to ensure message security.

It can be seen that the TLS1.2 protocol requires encryption suite negotiation, key information exchange, ChangeCipherSpec protocol notification and other processes, which consumes 2-RTT handshake time, which is also one of the important reasons for the slowness of the HTTPS protocol.

By capturing and analyzing the packet, we can see the entire encryption process:

Next, let's look at the interaction process of TLS 1.3, as shown in the figure:

After capturing the packet, as shown in the figure, you can see the entire encryption process of the client:

In TLS 1.3, the client first not only sends a list of supported ciphers in ClientHello, but also guesses which key negotiation algorithm the server will choose and sends a key share, which can save a large part of the overhead and thus improve the speed.

TLS1.3 provides a 1-RTT handshake mechanism. Taking the ECDHE key exchange process as an example, the handshake process is as follows. The process of the client sending the ECDH temporary public key is advanced to ClientHello, and the ChangeCipherSpec protocol is deleted to simplify the handshake process, so that only 1-RTT is required for the first handshake. Let's take a look at the specific process:

• The client sends a ClientHello message, which mainly includes the protocol version supported by the client and the DH key exchange parameter list KeyShare;
• The server replies with ServerHello, including the selected encryption suite; sends the certificate to the client; uses the private key corresponding to the certificate to sign the handshake message and sends the result to the client; selects the parameters provided by the client to generate an ECDH temporary public key, and combines the selected DH parameters to calculate the shared key used to encrypt HTTP messages; the temporary public key generated by the server is sent to the client via the KeyShare message;
• After receiving the KeyShare message, the client uses the certificate public key to verify the signature, obtain the server's ECDH temporary public key, and generate the shared key required for the session;
• Both parties use the generated shared key to encrypt and transmit messages to ensure message security.

If the client has been connected before, we have a way to do a 1-RTT connection in 1.2, while TLS 1.3 allows us to do a 0-RTT connection, as shown in the figure:

Of course, whether to use TLS1.2 or TLS1.3 depends on the actual business scenario and user group. Newer versions of browsers generally support the latest encryption protocols, while older browsers and operating systems such as IE 8 and Windows XP do not support them. If your users are customers of some government departments, then it is not suitable to use this newer technical solution, because as far as I know, many government departments' operating systems are still versions below XP and IE 8, which will cause the new protocol to not work properly in their operating systems. Therefore, you can configure more encryption algorithms and encryption protocols to be backward compatible with different clients.

Fourth, apply for certificates from reliable CA vendors, because unreliable vendors (such as certificate vendors that are not trusted by mainstream browsers) will randomly modify the certificate date and reissue certificates. In addition, even certificates issued by reliable CAs may be forged. For example, Symantec was previously exposed to a scandal and was punished by Firefox and Chrome. As a result, these mainstream browsers no longer trust some certificates issued by these CA organizations. Therefore, once a certificate is found to be untrusted, it must be replaced as soon as possible.

Fifth, use a complete certificate chain. If the certificate chain is incomplete, it is very likely that access exceptions will occur on some versions of browsers.

Sixth, use HTTP/2. Using the latest HTTP 2 can improve the access speed of the website and have better performance support.

Seventh, protect the certificate private key from being leaked.

Eighth, choose the right certificate according to your business needs. Certificates are divided into self-signed certificates, DV, EV and OV certificates. Generally speaking, if you only need to perform simple data encryption, you can use a DV certificate. This type of certificate can usually be applied for free, and you only need to perform a simple domain name owner verification to apply. EV and OV certificates are generally expensive and suitable for financial institutions or units with strict requirements for data encryption. The issuance procedures for this type of certificate are complicated and generally require corporate identity authentication before they are issued. Self-signed certificates are generally used by users for temporary testing and are not recommended for use in production environments because they are not issued by a trusted CA organization and browsers will not trust them.

After we have configured it, we can use https://www.ssllabs.com/ssltest/ to score your HTTPS site. If it is A+, it means that your site security is particularly high. As shown in the figure, if the score is not high, you can view the specific details to make more specific optimizations for your site.

Finally, here is a copy of the nginx configuration for reference:

 server
 {
 listen 443 ssl http2 default_server;
 server_name www.example.com;
 index   index .html index .htm index .php;
 root /web;
 ssl on ;
 ssl_certificate /nginx/ssl/awen/fullchain.cer;
 ssl_certificate_key /nginx/ssl/example/example.com.key ;
 ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH +ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS- CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EEC DH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES;
 ssl_prefer_server_ciphers on ;
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_session_cache shared:SSL:50m;
 ssl_session_timeout 1d;
 ssl_session_tickets on ;
 resolver 114.114.114.114 valid=300s;
 resolver_timeout 10s;
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" ;
 add_header X-Frame-Options deny;
 add_header X-Content-Type-Options nosniff;
 add_header CIP $http_x_real_ip;
 add_header Accept-Ranges bytes;
 }
 server {
 listen 80;
 server_name _;
 server_name www.example.com;
 return 302 https://$host$request_uri;
 }

Well, the above are the optimization suggestions for HTTPS sites that I shared with you.