|name||classification||give an example|
|1XX||Message status||100 continue|
|2XX||Request successful||200 request successful
202 the request succeeded, but no resource entity was returned
|3XX||redirect||301 permanent redirection
302 temporary redirection
|4XX||Client error||There is a syntax error in the 400 request
403 request rejected by server
404 the server could not find the requested resource
|5XX||Server error||500 server error
502 accept invalid response from upstream server
503 server is under maintenance or overloaded
First of all, to be clear, the emergence of HTTPS is to solve the problem of insecurity of HTTP plaintext data transmission. If we really want to achieve the data security transmission in network communication, we must first solve three problems: data confidentiality, data validity, data integrity and consistency
For data confidentiality: HTTPS (SSL / TLS) exchange key through asymmetric key, symmetric encryption transmission data guarantee
For data validity: HTTPS (SSL / TLS) is guaranteed by signature and authentication
For data integrity and consistency: HTTPS (SSL / TLS) is guaranteed by message digest algorithm (one-way hash algorithm)
HTTPS is not a new protocol, it is actually a combination of HTTP protocol and SSL (TLS) protocol, that is, a security protocol based on SSL (secure socket layer), that is, security is realized through SSL protocol.
SSL is a protocol between application layer and transport layer, which can provide security guarantee for any application layer protocol based on reliable connection such as TCPSSL uses authentication, data encryption and message integrity verification mechanism to provide security guarantee for data transmission on the network. SSL currently has three versions, ssl1.0, ssl2.0 and SSL3.0. It has been widely used in identity authentication and encrypted data transmission between web browser and server. SSL supports various application layer protocols.
SSL protocol can be divided into two layers: SSL record protocol (SSL record protocol): it is based on reliable transmission protocol (such as TCP), and provides basic functions such as data encapsulation, compression and encryption for high-level protocols. SSL handshake protocol (SSL handshake protocol): it is based on the SSL record protocol. It is used for identity authentication, encryption algorithm negotiation, encryption key exchange and so on before the actual data transmission.
TLS (Transport Layer Security) is the successor of SSL and the subsequent version of SSL 3.0. The protocol also consists of two layers: TLS record and TLS handshake.
The following figure shows the relationship between SSL / TLS and the transport layer and application layer, that is, the session layer in the OSI seven layer network model
- Authentication mechanism
Based on the certificate, the digital signature method is used to authenticate the server and the client, and the authentication of the client is optional.
- Confidentiality of data transmission
Symmetric key algorithm is used to encrypt the transmitted data.
- Message integrity verification
In the process of message transmission, MAC algorithm is used to check the integrity of the message.
SSL exchanges the encryption key in the process of data transmission through the handshake process to establish a secure link. Pay attention to the following points
- As the speed of asymmetric encryption is relatively slow, it is generally used for key exchange. Both sides negotiate a key through public key algorithm, and then communicate through symmetric encryption. Of course, in order to ensure the integrity of data, HMAC must be used before encryption.
- The handshake stage begins after the TCP connection is established. The handshake is actually in negotiation, negotiation of some parameter information required by the encryption and decryption protocol.
- The handshake process can be divided into one-way verification and two-way verification. For a brief explanation, one-way verification means that the server sends the certificate to the client, and the client verifies the validity of the server certificate. For example, for ordinary HTTPS websites such as Baidu, Sina, Google, etc., two-way verification means that not only the client will verify the validity of the server, but also the server will verify the validity of the client For example, bank online banking, Alipay landing transactions, etc.
SSL only authenticates the server by default, and the client authentication is optional.The flow chart is as follows:
Explain the four main communication processes in the figure above
- Request from client
-Supported protocol version number（SSLVersion), for exampleTLS 1.0Version.-A random number generated by the client (client random1), which will be used to generate later"Conversation key"。 -Support ciphers supported by clients, such as:RSAPublic key encryption algorithmDHEncryption algorithm.
- Server response (sever Hello, certificate, server key exchange, server Hello done)
In the figure above, from server hello to server done, some server implementations send each one separately, while some server implementations send together. Sever hello and server done are data with only header but no content. The main contents are as follows:
-Confirm the version of encrypted communication protocol used, such asTLS1.0edition. If the browser and server support different versions, the server will turn off encrypted communication.-A server generated random number (sever random), which will be used to generate later"Conversation key"。 -Confirm the encryption method used, such asRSAPublic key encryption.-Server certificate.
PS1: This is one-way verification. If it is two-way verification, you need to send a certificate request before sever Hello done, which means that the client needs to provide a certificate. The content is: the certificate type that the client should provide and the certificate list that the server can accept
At this time, the above two steps are still plaintext transmission!!!
- Client response (client key exchange, change chiper spec, encrypted handshake message)
PS1: if the server needs to verify the client, after the client receives the server Hello message, it first needs to send the client’s certificate to the server, so that the server can verify the legitimacy of the client.
-A random number (pre master secret). The client will generate a48This key contains the version number of the client TLS and a random number. If there are middlemen in total, it will be reduced intentionallyTLSVersion, the sending of data will be terminated immediately. That is, the protocol version is designed to resist the reverse attacks. The random number is encrypted with the server public key to prevent eavesdropping.-The change chiper spec indicates that the subsequent information will be sent with the encryption method and key agreed by both parties.-The client handshake end notification indicates that the client handshake phase has ended. This item is also the hash value of all the contents sent before, which is used for server verification.
As for why three random numbers must be used to generate the session key,dog250Well explained:
“Both the client and the server need random numbers, so that the generated key will not be the same every time. Because the certificate in TLS protocol is static, it is necessary to introduce a random factor to ensure the randomness of the key negotiated.
For RSA key exchange algorithm, the pre master key itself is a random number, plus the random number in the Hello message, three random numbers finally export a symmetric key through a key exporter.
The existence of pre master is that SSL protocol does not trust that every host can generate completely random numbers. If the random numbers are not random, then the pre master secret may be guessed, so it is not appropriate to only use the pre master secret as the key. Therefore, a new random factor must be introduced, that is, the client and server add the pre master Secret the key generated by three random numbers is not easy to guess. A pseudo-random number may not be random at all, but three pseudo-random numbers are very close to random. With each increase of one degree of freedom, the increase of randomness is not one. “
- New session ticket, change chiper spec, encrypted handshake message
new session ticket
The main purpose of this packet is that the server sends a new session ticket to the client, because there is no such information at the beginning, and notifies the client to start using encryption to transmit data. The session ticket is equivalent to a session in an ordinary website. When the browser sends a request or the connection is disconnected due to an intermediate network reason, and the client Hello stage carries the session ID, it is considered that the session ID is visited by the same person and is not in the certificate interaction stage. The reuse of the session ID is also an optimization point. The message is as follows
-Server transport change notification (change chiper spec)-The first encrypted handshake message on the server is used to make a simple verification of the previous handshake process!
Briefly summarize the above process:
The client and the server establish SSL Handshake: the client confirms the identity of the server through the CA certificate; passes three random numbers to each other, and then generates a key through the random number; confirms the key to each other, and then the handshake ends; when the data communication starts, the same session key is used to encrypt and decrypt; when the data communication starts, the same session key is used to encrypt and decrypt;
We can find that both symmetric encryption and asymmetric encryption are used in the process of the principle of HTTPS encryption. It not only makes use of the high security characteristic of asymmetric encryption, but also makes use of the advantages of fast speed and high efficiency of symmetric encryption.
2.5 extension: what is Ca? And the role in the whole handshake process
Certification bodyCA(certificate authority) is a very important role in HTTPS,CAyesPKIThe core executive body of the company isPKIThe main component of public key infrastructure (PKI) is usually called certification authority. Broadly speaking, certification authority should also include certificate application and registration authorityRA(registration authority), which is the management organization of digital certificate application registration and certificate issuance. How does the client verify the authority of the certificateCAThe center is legal and effective. In fact, it is embedded in the system browserCAThe root certificate of the center, in which the root certificate is a trusted institution.
- The certification authority generates a pair of secret keys, public keys and private keys
- Then the digital signature of the server (requester) is generated
- The server public key generates digital fingerprint by digital digest algorithm
- The generated digital fingerprint is encrypted with the private key of the certification authority to generate a digital signature
- Finally, the public key certificate is generated by using private key encryption, which mainly includes two parts: digital signature and server public key
The server sends the public key certificate to the client, and the client verifies the public key certificate to ensure the legitimacy of the public key.
1. Client retrievalPublic key of certification authority built in mobile phone in advance
2. Using the public key of the certification authority to decrypt the digital signature in the public key certificate to get the digital fingerprint
3. The client carries on the digital digest algorithm to the server public key of the public key certificate to generate the digital fingerprint
4. Compare whether the digital fingerprint generated by the client (step 3) and the digital fingerprint obtained by decryption (step 2) are consistent. If they are consistent, the public key certificate can be verified, and the server can be trusted. If they are not equal, then the certificate is wrong and may be usurped. The browser will give a relevant prompt, and the HTTPS connection cannot be established. In addition, the validity time of CA certificate and domain name matching will be verified.
When strengthening SSL / TLS based services, two configuration parameters are crucial: the allowed SSL / TLS version and the allowed cipher suite. These parameters should be set according to best practices, but they are not always clear; moreover, in an evolving security world, yesterday’s best advice to address a security issue could become today’s vulnerable configuration.
Five versions of SSL / TLS are widely supported in the library code: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2.
|SSL 2.0||Published in 1995. It contains many design defects of cryptanalysis, which can not be solved without breaking the protocol, and may lead to the exposure or modification of confidential data.||Disable this protocol|
|SSL 3.0||Released in 1996 as a complete redesign. Google’s pool attack uses browser script function and SSL 3.0 to launch man in the middle attack, which may lead to the exposure or modification of confidential data.||Disable this protocol|
|TLS 1.0||It was released in 1999 as a revision of SSL 3.0. TLS 1.0 vulnerable to beast attack||Disable TLS 1.0; if backward compatibility issues occur, re enable it.|
|TLS 1.1||Published in 2006 as a revision of TLS 1.0. The modification of the protocol includes a new IV generation scheme; therefore, TLS 1.1 is not susceptible to beast.||Enable TLS 1.1.|
|TLS 1.2||It was released in 2008 as a revision of TLS 1.1. TLS 1.2 introduces useful features, such as higher performance GCM cipher suite and sha-256-based pseudo-random functions.||Enable TLS 1.2.|
- Key exchange algorithm
- Data encryption algorithm
- Message verification algorithm（ MAC:Message Authentication Code）。
Key exchange algorithmAsymmetric encryption algorithm is used to establish channel in handshake.
Data encryption algorithmSymmetric encryption algorithm is generally used for encrypted data transmission after channel establishment.
Message verification algorithmHash is a kind of hash used to verify the integrity of the message, including the integrity of the whole handshake process (for example, the last step of TLS handshake is a complete hash calculation process of the existing handshake message).
How to choose each algorithm?
ECC certificate and ecdhe handshake are preferred. If the client does not support or only has RSA certificate, RSA certificate and ecdhe key exchange algorithm will be selected, but RSA key exchange algorithm has not been selected. Only when ecdhe key exchange algorithm is not supported can RSA be used for key exchange
(RSA key exchange, DH and DHE key exchange algorithms are less used in practice. Ecdhe has gradually become the mainstream. )
ECDHEEncryption algorithm is mainly based on forward security – that is, the security of historical communication!
This work adoptsCC agreementReprint must indicate the author and the link of this article