Today is the last lecture of “Security”. We have learned most of the knowledge related to HTTPS and TLS. However, you may still have some confusion:
“HTTPS is so complicated. Should I migrate to HTTPS? What benefits can it bring? How should I implement the migration specifically?”
These questions are not only for you, but also for many other people, as well as my real thoughts at the time, so let’s talk about this aspect today.
Necessity of migration
If you are engaged in mobile application development, you must know that development platforms such as Apple, Android, and Xinxin successively issued notices in 2017, requiring all applications to use HTTPS connections and prohibiting unsafe HTTP.
On desktop computers, mainstream browsers such as Chrome and Firefox have also begun to “forcefully promote” HTTPS and label HTTP sites as “unsafe” to put “psychological pressure” on users.
Search giants such as Google also use their “voice” advantage to lower the ranking of HTTP sites and give greater weight to HTTPS, trying to allow netizens to only access HTTPS websites.
These methods have gradually “squeezed” the living space of pure plaintext HTTP. “Migrating to HTTPS” is no longer a question of “whether to do it”, but “how to do it”. The tide of HTTPS is unstoppable. If you still stick to HTTP, it will undoubtedly be washed away into the corner of the Internet.
At present, many well-known large websites at home and abroad have implemented “full-site HTTPS”. When you open the commonly used websites such as Aubao, Dongdong, and Lang, you can see a “little lock” in the address bar of the browser. If you are using The website you maintain has not yet implemented HTTPS, so you need to hurry up.
Concerns about migration
According to my observation, there are still some concerns that hinder the implementation of HTTPS. I have summarized three popular views: “slow, expensive and difficult”.
The so-called “slow” refers to inertial thinking, using previous data to evaluate the performance of HTTPS, believing that HTTPS will increase the cost of the server, increase the delay of the client, and affect the user experience.
In fact, the computing capabilities of both servers and clients have been greatly improved. There is no need to worry about performance, and many optimization solutions can be applied (see Lecture 28). According to evaluations by companies such as Google, after proper optimization, the additional CPU cost of HTTPS is less than 1%, and the additional network cost is less than 2%, which can be said to be almost the same as HTTP without encryption.
The so-called “expensive” mainly means that the cost of certificate application and maintenance is too high for the website to bear.
This is also an inertial thinking, and it was indeed a problem in the early years. The process of applying for a certificate from a CA was not only troublesome, but also expensive, with thousands or even tens of thousands of yuan required to be paid every year.
But things are different now. In order to promote HTTPS, many cloud service vendors provide one-click application and low-cost certificates, and there are also CAs that specialize in issuing free certificates. The most famous one is “Let’s Encrypt< /strong>“.
The so-called “difficulty” means that HTTPS involves too many knowledge points, is too complex, and has a certain technical threshold, making it difficult to get started quickly.
This third concern is more realistic. HTTPS is related to many fields such as cryptography, TLS, PKI, etc. It cannot be mastered in just a few weeks or months. But implementing HTTPS does not require a complete mastery of these. You only need to grasp a few key points. Now I will help you solve some key “difficulties” one by one.
Application for certificate
To switch a website from HTTP to HTTPS, the first thing to do is to apply for a certificate for the website.
For reasons of reputation and company image, large websites usually choose to apply for certificates from traditional CAs, such as DigiCert and GlobalSign. However, small and medium-sized websites can choose to use free certificates such as “Let’s Encrypt”, and the effect is not inferior to those of those Fee certificate.
Let’s Encrypt has been promoting the automated deployment of certificates and has implemented a dedicated ACME protocol (RFC8555) for this purpose. There are many client software that can complete the “one-stop” operation of application, verification, download, and update, such as Certbot, acme.sh, etc., which can be found on the “Let’s Encrypt” website. The usage is very simple, and the relevant documents are also It’s very detailed and can be completed in a few minutes, so I won’t go into details here.
But I must remind you of a few things.
First, when applying for a certificate, you should apply for both RSA and ECDSA certificates, and configure dual certificate verification in Nginx so that the server can automatically select a fast elliptic curve certificate and is also compatible with clients that only support RSA.
Second, if you apply for an RSA certificate, the private key must be at least 2048 bits, and the digest algorithm should be SHA-2, such as SHA256, SHA384, etc.
Third, for security reasons, the validity period of the “Let’s Encrypt” certificate is very short, only 90 days. It will expire when the time is up, so it must be updated regularly. You can add a weekly or monthly task to the crontab and send an update request, but many ACME clients will automatically add such regular tasks without you having to worry about it.
Configure HTTPS
After getting the certificate, the next step is to configure the web server and enable the HTTPS service on port 443.
This is very simple on Nginx. Just add the parameter “ssl” after the “listen” command and the certificate file just now to implement the most basic HTTPS.
listen 443 ssl; ssl_certificate xxx_rsa.crt; #rsa2048 cert ssl_certificate_key xxx_rsa.key; #rsa2048 private key ssl_certificate xxx_ecc.crt; #ecdsa cert ssl_certificate_key xxx_ecc.key; #ecdsa private ke
In order to improve the security and performance of HTTPS, you can also force Nginx to only support protocols above TLS1.2 and turn on “Session Ticket” session reuse:
ssl_protocols TLSv1.2 TLSv1.3; ssl_session_timeout 5m; ssl_session_tickets on; ssl_session_ticket_key ticket.key;
In terms of cipher suite selection, my advice to you is to give priority to the server’s suite. This prevents malicious clients from deliberately selecting weaker suites, lowering the security level, and then “aligning” the cipher suites to TLS1.3, using only ECDHE, AES and ChaCha20, and supporting “False Start”.
ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE + AES128:!MD5:!SHA1;< /pre> <p>If you use BorringSSL, a branch of OpenSSL, on your server, you can also use a special "Equal preference cipher groups" feature, which allows the server to configure a set of "equivalent" cipher suites. The suite allows client preference, for example, configured like this:</p> <pre>ssl_ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305];
If the client hardware is not optimized for AES, the server will follow the client’s wishes and give priority to the ChaCha20 algorithm that is “equivalent” to AES, so that the client can be faster.
After all configurations are completed, you can visit the “SSLLabs” website to test the security of the website. It will simulate a variety of clients to initiate tests and give a comprehensive score.
The picture below shows the rating results of the GitHub website:
Server name indication
There is also a “virtual host” issue that needs to be resolved when configuring the HTTPS service.
In the HTTP protocol, multiple domain names can run on one IP address at the same time. This is a “virtual host”, and the web server will use the Host field in the request header (see Lecture 9) to select.
But in HTTPS, because the request header can only be sent after the TLS handshake, the certificate corresponding to the “virtual host” must be selected during the handshake. TLS cannot know the domain name information, so it can only use the IP address to distinguish it. Therefore, in the early days, each HTTPS domain name had to use an independent IP address, which was very inconvenient.
So how to solve this problem?
This still requires the use of TLS “extensions” and adding a “supplementary clause” of SNI (Server Name Indication) to the agreement. Its function is similar to the Host field. The client will bring the domain name information when “Client Hello”, so that the server can select the certificate based on the name instead of the IP address.
Extension: server_name (len=19)
Server Name Indication extension
Server Name Type: host_name (0)
Server Name: www.chrono.com
Nginx has long supported HTTPS virtual hosts based on the SNI feature, but you can also write Lua scripts in OpenResty and use databases such as Redis and MySQL to load certificates more flexibly and quickly.
Redirect jump
Now that there is an HTTPS service, the original HTTP site cannot be abandoned immediately. There are still many netizens who are used to typing the domain name (or old bookmarks or hyperlinks) directly in the address bar and accessing it using the HTTP protocol by default.
Therefore, we need to use the “redirect jump” technology in Chapter 18 to “redirect” the unsafe HTTP URL to the new HTTPS website using 301 or 302. This is also easy to do in Nginx. , you can use “return” or “rewrite”.
return 301 https://$host$request_uri; #Permanent redirection rewrite ^ https://$host$request_uri permanent; #Permanent redirect
But there are two problems with this approach. One is that redirection increases network costs and requires one more request; the other is that there are security risks. The redirected response may be tampered with by a “middleman” to achieve “session hijacking” and jump to a malicious website.
However, there is a technology called “HSTS” (HTTP Strict Transport Security) that can eliminate this security risk. The HTTPS server needs to add a “Strict-Transport-Security” field to the response header sent out, and then set a validity period, for example:
Strict-Transport-Security: max-age=15768000; includeSubDomains
This is equivalent to telling the browser: My website must strictly use the HTTPS protocol, and HTTP is not allowed within half a year (182.5 days). You can make the conversion yourself in the future, and don’t bother me again.
With the “HSTS” instruction, when the browser accesses the same domain name in the future, it will automatically change the “http” in the URI to “https” and directly access the secure HTTPS website. In this way, the “man-in-the-middle” loses the opportunity to attack, and it also eliminates a jump for the client, speeding up the connection speed.
For example, if you use the “add_header” command to add the “HSTS” field in the experimental environment configuration file:
add_header Strict-Transport-Security max-age=15768000; #182.5days
Then the Chrome browser will only use the HTTP protocol during the first connection, and will use the HTTPS protocol thereafter.
Summary
Today we introduce some technical points of HTTPS migration. Once you master them, you can build a complete HTTPS site.
However, if you want to implement “full-site HTTPS” for large websites, you still need to do a lot of detailed work, such as using various instructions and tags of CSP (Content Security Policy) to configure security policies, and using reverse proxies to centrally “uninstall” “SSL.
A brief summary of today’s content:
Migrating from HTTP to HTTPS is a “general trend”, and you should do it as soon as possible if you can;
To upgrade HTTPS, you must first apply for a digital certificate. You can choose the free and easy-to-use “Let’s Encrypt”;
When configuring HTTPS, you need to pay attention to selecting the appropriate TLS version and cipher suite to strengthen security;
The original HTTP site can be left as a transition, using 301 redirects to HTTPS.
The knowledge points of the article match the official knowledge files, and you can further learn related knowledge. Network skill treeProtocol supporting applicationsHTTP protocol 42140 people are learning the system