HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, Hypertext Transfer Protocol based on Secure Socket Layer) is an HTTP channel aimed at security. Simply put, it is a secure version of HTTP. That is, the SSL layer is added to HTTP. The security foundation of HTTPS is SSL. The identity of the server is verified through the SSL certificate and the communication between the browser and the server is encrypted. The port number used is 443.
SSL and TLS
SSL: SSL (Secure Socket Layer) is a secure transmission protocol designed by Netscape mainly for the web. This protocol has been widely used on the WEB. Certificate authentication ensures that the communication data between the client and the website server is encrypted and secure.
The SSL protocol is located between the TCP/IP protocol and various application layer protocols, providing security support for data communication. The SSL protocol can be divided into two layers: SSL Record Protocol: It is built on a reliable transmission protocol (such as TCP) and provides support for basic functions such as data encapsulation, compression, and encryption for high-level protocols. SSL Handshake Protocol: It is built on the SSL record protocol and is used by the communicating parties to authenticate identities, negotiate encryption algorithms, and exchange encryption keys before actual data transmission begins.
TLS: TLS (Transport Layer Security, Transport Layer Security Protocol) is used to provide confidentiality and data integrity between two applications.
When SSL developed to v3, it had proven itself to be a very good secure communication protocol, so the Internet Engineering Group IETF renamed it TLS (Transport Layer Security) in 1999, officially standardized it, and the version number was renamed from 1.0. Counting, so TLS1.0 is actually SSLv3.1. TLS 1.0 is a new protocol developed by the IETF (Internet Engineering Task Force, Internet Engineering Task Force). It is based on the SSL 3.0 protocol specification and is a subsequent version of SSL 3.0. It can be understood as SSL 3.1 (can be simply understood as Different names for the same thing at different stages). The protocol consists of two layers: TLS Record and TLS Handshake. The lower layer is the TLS record protocol, which sits on top of a reliable transport protocol (such as TCP). The main goal of TLS is to make SSL more secure and to make the specification of the protocol more precise and complete.
TLS has developed three versions, namely 1.1 in 2006, 1.2 in 2008 and 1.3 in 2018. Each new version closely follows the development of cryptography and the current status of the Internet, continuously strengthens security and performance, and has become an authoritative standard in the field of information security.
The most widely used TLS currently is 1.2, and previous protocols (TLS1.1/1.0, SSLv3/v2) have been considered insecure.
Why use HTTPS
The HTTPS protocol is mainly to solve the security problems of the HTTP protocol. Using the HTTP protocol for transmission has the following risks:
(1) Eavesdropping risk, for example, the communication content can be obtained on the communication link, thereby stealing the user account.
(2) Risk of tampering, such as forced planting of spam advertisements, causing visual pollution.
(3) Impersonation risks, such as pretending to be someone else’s identity to make purchases, causing users to lose money.
HTTPS principle
HTTPS supplements SSL/TSL at the application layer and network layer. HTTP request/response can generally be divided into six steps: (1) Establish a TCP connection; (2) Send an HTTP request; (3) The server processes the request; (4) Returns an HTTP response; (5) Releases the TCP connection; (6) The browser parses the returned resources and data. However, HTTPS adds an SSL connection establishment process after completing the TCP connection establishment. After establishing a secure connection, HTTP requests and other subsequent matters are sent. Next, we will focus on the process of establishing a connection via SSL (here, TLS 1.2).
(1) After the TCP connection is established, the browser will first send a "Client Hello" message, which is to "greet" the server. It contains the client version number, supported cipher suites, and a random number (Client Random) plain text for subsequent generation of session keys .
(2) After the server receives the "Client Hello", it will return a "Server Hello" message. Check the version number and give a random number (Server Random) plain text, and then select a cipher suite from the cipher suite list provided by the client as the cipher suite used for this communication (such as the ECDHE algorithm). At the same time, in order to prove its identity, the server also sends the certificate (Server Certificate) to the client. Because the server has selected a cipher suite, it will send a "Server Key Exchange" message after the certificate, which contains the public key (Server Params) to implement the key exchange algorithm, plus its own private key signature authentication.
This is followed by the "Server Hello Done" message, which means "greeting is complete". This completes the first message round trip (two TCP packets), and the result is that the client and server share three pieces of information in clear text: Client Random, Server Random, and Server Params.
(3) After the browser obtains the server's certificate, it begins to confirm the authenticity of the certificate and uses the certificate's public key to verify the signature. After confirming the server's identity, the browser generates a public key (Client Params) based on the selected cipher suite, and then sends it to the server using the "Client Key Exchange" message. Now the browser and server have the two parameters of the key exchange algorithm (Client Params, Server Params), and then use the cipher suite algorithm to calculate the "Pre-Master". Now the browser and server have three random numbers: Client Random, Server Random and Pre-Master. Using these three as raw materials, you can generate the master key used to encrypt the session, called "Master Secret". And because the hacker can't get the "Pre-Master", he can't get the master key.
Why do we need three random numbers: Client Random, Server Random and Pre-Master? This is mainly because the TLS protocol does not trust the reliability of the browser or server's pseudo-random numbers. In order to ensure that it is truly "completely random" and "unpredictable", it mixes three unreliable random numbers, so "random" The level is higher and the security is more guaranteed.
With the master key and the session secret derived based on the master key, the handshake is almost over. The browser sends a "Change Cipher Spec" message, and then sends a "Finished" message to digest all previously sent data, encrypt it, and let the server verify it.
(4) After receiving the browser's verification request, the server follows the same steps and sends "Change Cipher Spec" and "Finished" messages respectively.
(5) After completing the above operations, the TSL connection is established, and the next step is to send HTTP requests and responses in an encrypted manner.
Why use certificates
Simply put, the certificate + digital signature method can ensure that the certificate content is not tampered with and prevents "man-in-the-middle attacks". It is equivalent to telling the browser how to verify the identity of the server, that is, one-way authentication.
One-way authentication and two-way authentication
One-way authentication means that the client needs to authenticate the server.
The principles of two-way authentication and one-way authentication are basically the same. The main difference is that in addition to the client needing to authenticate the server, the server also needs to authenticate the client. In what scenarios do we need to verify the client? For example, in some banking services, the bank will require the customer to insert the USB shield issued by them into the computer, or install some control. This is similar to the concept of client certificate. People without this certificate cannot use the services provided by the bank.
Do I have to do a handshake at the SSL/TLS layer to transfer keys every time I make an HTTPS request?
It is very time-consuming to go through the key transmission process for each request, so how to achieve only one transmission? The server will maintain a session ID for each browser and pass it to the browser during the TLS handshake phase. After the browser generates the key and passes it to the server, the server will save the key under the corresponding session ID. After that, the browser will Each request will carry the session ID, and the server will find the corresponding key based on the session ID and perform decryption and encryption operations, so that there is no need to re-create and transmit the key every time.
Does HTTPS use symmetric encryption or asymmetric encryption?
To answer this question, we need to review the principles of HTTPS. See above for HTTPS principles.
After introducing the principle of HTTPS, you can know that HTTPS uses asymmetric encryption to transmit a symmetric key, so that both the server and the browser can know it. Both parties then use this symmetric key to encrypt and decrypt the sent and received data. Because the transmission key K uses asymmetric encryption, it is difficult to crack and is more secure. The specific transmission data uses symmetric encryption to speed up the transmission. Best of both worlds.
How cloud services implement HTTPS
For cloud services, it is not necessary to implement HTTPS in every microservice. There are also many articles on the Internet about implementing HTTPS for Spring Boot, which is misleading. For cloud services, it only needs to be implemented at the service entrance. There are two common implementation scenarios, one is static resource-oriented CDN, and the other is service-oriented LB. Of course, other situations such as firewalls may also be included. For details, please refer to these two WIKIs: One article will help you understand HTTPS configuration on Alibaba Cloud and Tencent Cloud's full-site HTTPS solution .
For developers and architects, they only need to understand the principles of HTTPS, and when they need to implement HTTPS, implement HTTPS configuration on the corresponding components according to the existing design, and this configuration generally relies on the cloud platform.
Disadvantages of HTTPS
The HTTPS protocol has the following shortcomings:
(1) The HTTPS protocol has multiple handshakes, which increases the page loading time by nearly 50%.
(2) HTTPS connection caching is not as efficient as HTTP and will increase data overhead and power consumption.
(3) Applying for an SSL certificate costs money, and the more powerful the certificate, the higher the cost.
(4) The security algorithms involved in SSL consume CPU resources and consume a large amount of server resources.
The difference between HTTP and HTTPS
HTTP is a hypertext transfer protocol, and information is transmitted in clear text, which poses security risks. HTTPS solves the insecurity shortcomings of HTTP and adds the SSL/TLS security protocol between the TCP and HTTP network layers so that messages can be encrypted and transmitted.
HTTP connection establishment is relatively simple, and HTTP message transmission can be carried out after the TCP three-way handshake. After the three-way handshake of TCP, HTTPS still needs to carry out the SSL/TLS handshake process before it can enter encrypted message transmission.
The port number of HTTP is 80, and the port number of HTTPS is 443.
The HTTPS protocol requires applying for a digital certificate from a CA (certificate authority) to ensure that the server's identity is trustworthy.
reference
https://blog.csdn.net/hguisu/article/details/8680808 HTTPS implementation principle
https://zhuanlan.zhihu.com/p/466239718 Interview essentials: Sixty-two questions frequently asked in computer networks
https:/ /zhuanlan.zhihu.com/p/27395037 HTTPS series dry information (1): Detailed explanation of HTTPS principles
https://www.zhihu.com/tardis/zm/art/72616216 How to understand the HTTP and HTTPS protocols in ten minutes?
https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3
https://developer.mozilla.org/zh-CN/docs/Web/Security/Transport_Layer_SecurityTransport Layer Securityhttps
://www.cnblogs.com /huansky/p/13977181.html HTTPS in simple terms (detailed version)
https://zhuanlan.zhihu.com/p/43789231 Thoroughly understand the encryption principle of HTTPS
https://zhuanlan.zhihu.com/p/96494976 You know, Does HTTPS use symmetric encryption or asymmetric encryption?
https://www.jianshu.com/p/918d9f517749 Symmetric encryption and asymmetric encryption in https
https://zhuanlan.zhihu.com/p/162082184 Symmetric or asymmetric - what is used in https?
https://cloud.tencent.com/document/product/400/6813Tencent Cloud implements full-site HTTPS solution
https://help.aliyun.com/practice_detail/444367 This article will help you understand the HTTPS configuration on Alibaba Cloud