Recently looked at a lot of cattle guest posts, found that whether the club or school recruitment, a few rounds of technical interview down will test this problem, at the same time this problem can also be extended out of a lot of small knowledge points, let’s talk about this knowledge points
HTTP profile
Let’s start with a general definition of all evil:
HTTP is short for Hyper Text Transfer Protocol. It is used to Transfer hypertext from the World Wide Web server to the local browser. HTTP is a TCP/ IP-based communication protocol to transfer data (HTML files, image files, query results, etc.). HTTP is an object-oriented protocol belonging to the application layer. Because of its simple and fast way, it is suitable for distributed hypermedia information system. It was put forward in 1990. After several years of use and development, it has been constantly improved and expanded. Currently, HTTP/1.0 version 6 is used in the WWW. HTTP/1.1 standardization work is under way, and the proposal of HTTP-NG(Next Generation of HTTP) has been put forward. The HTTP protocol works on a client-server architecture. As the HTTP client, the browser sends all requests to the HTTP server, namely the WEB server, through the URL. The Web server sends a response message to the client based on the received request.Copy the code
Ok, so that’s the definition of the annoying concept, so instead of memorizing it by rote, we can briefly analyze the characteristics of HTTP.
HTTP features
This issue was covered in the last post, so we can review it briefly:
-
Flexible and extensible, mainly reflected in two aspects. One is semantically free, specifying only basic formats, such as separating words with Spaces and separating fields with newlines, while other parts have no strict syntactic restrictions. Another is the variety of transmission forms, not only can transmit text, but also can transmit pictures, videos and other arbitrary data, very convenient.
-
Reliable transmission. HTTP is based on the TCP/IP protocol, so it inherits this feature.
-
Request-reply. Can be a general situation for a collection, have come back. The requester and responder are not just between the client and the server. If a server acts as a proxy to connect to the server on the back end, the server also acts as the requester.
-
Stateless. Each HTTP request is independent and unrelated, and by default no context state information about the communication process needs to be retained.
-
Support for B/S and C/S modes.
The disadvantages of HTTP
When we send private data to the server (such as your bank card, ID card), if we use HTTP communication. Then security will not be guaranteed.
First of all, during data transmission, the data may be captured by middlemen, so the data will be stolen by middlemen. Secondly, after the data is taken by the middleman, the middleman may modify or replace the data and then send it to the server.
Finally, when the server receives the data, it cannot determine whether the data has been modified or replaced. Of course, if the server does not know the data is really from the client.
In short, it can be summarized as three disadvantages:
-
Confidentiality of messages cannot be guaranteed
-
Message integrity and accuracy cannot be guaranteed
-
The reliability of the source cannot be guaranteed
HTTPS was born. Let’s take a look at HTTPS.
HTTPS
HTTPS is a secure HTTP channel, which is simply the secure version of HTTP.
That is, add SSL layer to HTTP, and SECURE Sockets Layer (SSL) is the basis of HTTPS security. Therefore, SSL is required for details of encryption. It is now widely used for security-sensitive communications on the World Wide Web, such as transactions and payments. HTTPS uses an asymmetric encryption algorithm to make it impossible to reverse the plaintext.
Now let’s see what the specific workflow is.
We can think of the two sides of communication as client and server. Then go through the following stages.Copy the code
- First, the client applies for HTTPS communication.
- The server responds and passes the certificate to the client.
- The client authenticates the certificate, obtains the public key, generates a symmetric encryption key, encrypts the key with the public key, and sends the key to the server.
- The server receives the message, decrypts it with the private key, produces the symmetric key, and notifies the client that the SSL channel has been established and the HTTPS communication has been established.
- After the shared key is exchanged successfully and HTTPS communication is established, the client and server use the shared key to encrypt communication.
- Finally, the client disconnects.
As can be seen from the above, HTTPS establishment to disconnection can be divided into 6 stages, but there are also 12 processes, we can do a simple analysis of these 12 processes below.
-
Client – Hello: The Client sends a Client Hello packet to initiate SSL communication. The packet contains the specified VERSION of SSL supported by the client, Cipher Suite list (encryption algorithm used, and key length).
-
Server-hello: When SSL communication is enabled, the Server responds with Server Hello packets. As with the client, the message contains the SSL version as well as the encryption component. The server’s encryption component content is filtered from the received client encryption component.
-
Server – Certificate sending: The server sends certificate packets. The message contains a public key certificate.
-
Server – I’m Done: At the end, the Server sends a Server Hello Done message to notify the client that the initial SSL handshake negotiation is complete.
-
Client – Send Key: After the first SSL handshake, the Client responds with a Client Key Exchange packet. The message contains a random password string called pre-master secret used in communication encryption. The message has been encrypted with the public key described in Step 3.
-
Client – Just use this secret key: The message will prompt the server that all communications following this message will be encrypted using the Premaster Secret key.
-
Client – I’m done: this packet contains the global checksum of all the packets so far connected. Whether the handshake negotiation can succeed depends on whether the server can decrypt the packet correctly.
-
Server – Sends a Change Cipher Spec message (I am receiving the secret key).
-
Server – Sent the Finished message (I received the secret key).
-
Client – Start sending body: The server sends an HTTP request and related content.
-
Server – Start receiving body: The client receives the HTTP request and processes the content.
-
. Client – Disconnect: The client is finally disconnected. When the connection is disconnected, the close_notify packet is sent. After this step, a TCP FIN packet is sent to close the communication with TCP.
At the same time, the application layer attaches a Message Authentication Code (MAC) digest to the data it sends. MAC checks whether packets are tampered to ensure packet integrity.
Theoretical principles of HTTPS
HTTPS uses some encryption and decryption, digital certificate, digital signature technology to achieve. Here are the basic concepts of these technologies.
Symmetric and asymmetric encryption
1. Symmetric encryption (shared key encryption) : The client and server share a key to encrypt and decrypt messages. This method is called symmetric encryption. The client and server agree on an encrypted key. The client encrypts the message with the key before sending it. After sending the message to the server, the server decrypts the message with the key.
You can take a look at a picture to get an idea.
In the preceding figure, M indicates plain text, C indicates key, and N indicates ciphertext.
Advantages of symmetric encryption
- Symmetric encryption solves the problem of message confidentiality in HTTP.
Disadvantages of symmetric encryption
-
Symmetric encryption guarantees message confidentiality, but because the client and server share the same key, it makes the key especially vulnerable to disclosure.
-
Because of the high risk of key disclosure, it is difficult to guarantee the reliability of the source, the integrity and accuracy of the message.
As can be seen from the above, symmetric encryption key disclosure risk is very high, the secret key is fixed, leading to easy cracking, so is there a better way to encrypt transmission, for example, each time the use of the secret key is not the same, each time the decryption of the secret key is not the same, or other situations to increase security?
Asymmetric encryption
Since symmetric encryption, the key is so easy to leak, so we can use an asymmetric encryption way to solve the problem.
When asymmetric encryption is used, both the client and server have a public key and a private key. The public key can be exposed, but the private key can only be seen by itself.
A message encrypted with a public key can only be unlocked by the corresponding private key. Conversely, messages encrypted with the private key can only be unlocked by the public key. In this way, the client encrypts the message with the server’s public key before sending it, and the server decrypts the message with its private key after receiving it.
Graphic encryption process:
M indicates the text, D indicates the public key, E indicates the private key, and N indicates the ciphertext.
Generate public key D and private key E on the server this time, and keep the private key. Then public key D is made public. The client that wants to communicate with the server uses public key D to encrypt it and sends it to the server with private key E. The server uses private key E to decrypt the ciphertext and finally get the plaintext.
As for the encryption algorithm mentioned just now, the more famous is RSA public key encryption algorithm, his encryption process does not do too much analysis, want to know more can be according to the following connection, their own understanding.
Blog.csdn.net/u014044812/…
Digital certificates and signatures
In order to solve the unsecurity of public key source in asymmetric encryption. We can solve this problem by using digital certificates and digital signatures.
Application for digital certificates
In reality, there are specialized authorities that issue digital certificates. We call these authorities certification Authorities (CAS).
The server can apply for digital certificates from these cas.
The application process is roughly as follows:
- You form a pair of keys and then go to CA to apply for a digital certificate with your public key and other information (such as the name of your company).
- After receiving the information, CA will select a one-way Hash algorithm (such as MD5) to encrypt the information, which is called digest.
- One of the characteristics of the one-way Hash algorithm is that it is one-way and irreversible. As long as the original content changes a little, the encrypted data will be very different (of course, there is a small possibility of repetition, if you are interested in the pigeon nest principle), so as to prevent information tampering.
- After the abstract is generated, CA will encrypt the abstract with its own private key. The encrypted data of the abstract is called digital signature.
- Finally, the CA will combine our application information (including the server’s public key) with the digital signature to generate a digital certificate. The CA then passes the digital certificate to us.
How do digital certificates work
After obtaining the digital certificate, the server sends it to the client. The client uses the CA public key to decrypt the digital certificate and verify its validity. So how do we get the CA public key? Our computers and browsers already have some of the authority’s root certificates built in, and these root certificates contain CA public keys.
Is the root certificate, because in real life, certification center is hierarchical level, that is to say, there are top certification center, also have the following each child certification center, is a tree structure, embedded in the computer is one of the most top institutions root certificate, but don’t worry, root certificate’s public key is also applicable in children.
The client uses the CA public key to decrypt the digital certificate. If the decryption succeeds, the certificate is from a legitimate authority. Once decrypted, the client gets the digest.
In this case, the client generates a summary of the application information based on the Hash algorithm used by the CA and compares the summary with the decrypted one. If they are the same, the content is complete and has not been tampered with. Finally, the client securely obtains the server’s public key from the certificate and can communicate with the server in secure asymmetric encryption. The server can obtain the public key of the client in the same way.