Reprint from HTTP to HTTPS

Reprinted from Http://www.cnblogs.com/silin6/p/5928503.html

HTTP

When you enter a URL in the browser (for example, http://tasaid.com), the browser initiates an HTTP request with the request information (see HTTP Headers), connects to the server, passes the request information to the server, and the server receives the information, parses the relevant information, It then processes and returns the data requested by the browser.

In a nutshell, this is a process:

1. Xiao Ming and the browser dad said I want to go to a store in Zhongguancun to get some things (initiating a request)
2. Browser dad put the things Xiao Ming wanted on a list (generate HTTP protocol)
3. Then the browser dad sent a line Cheng , miso and miso to run to the Zhongguancun store, the list handed to the shop, said Xiaoming want these things (carry on transmission)
4. The store let the line Cheng Wait, then went to the house to take Xiaoming's these things (the server received the request)
5. After the store took the things out, and also printed a list, so that the line Cheng with the list and things together take back (server processing request completed)
6. Then the line Cheng back to the browser dad , the server to the list and items to the browser dad, browser dad according to inventory check items (browser processing response)
7. And then pack the items to xiaoming (the browser renders and renders the interface)

Look at the words:

There is a problem with both the browser's father and the server not verifying the validity of the inventory information and the identity of the other person. What if someone in the middle of the line Cheng down, beating a meal, and then the list of items to change what to do? Or someone put the line Cheng on the way to beat a meal, took the list for another small brother to do?

This is a very serious problem: if the server to put something locked in the cupboard, need xiaoming to password to open the cabinet. Then Xiaoming writes the password on the list to let the browser father to the server. At this time, if the list was intercepted, do not get Xiaoming's password?

Simply put, the transmitted information contains the user's password and is intercepted.

HTTPS

Because the HTTP request has these security issues, so HTTPS was born, dedicated to address these security issues, we make a comparison:

Security	HTTP	HTTPS
Eavesdropping risk	The information passed is clear, and may be intercepted and tapped.	Information encryption Propagation
Tamper risk	The information passed may be tampered with	Information verification, once tampered with, will be detected immediately.
Camouflage risk	Not verifying the identity of the other side of the communication, may encounter camouflage	Identity check

So how can https be more secure?

Simply put, HTTPS is a layer of SSL encryption under HTTP, so it's called HTTPS. The specific encryption process is the public key encryption method:

• The client asks for a public key from the server and then encrypts the information using the public key
• The server receives encrypted information and decrypts it with its own private key.

Both the public key password and the algorithm are public, while the private key is confidential. The keys used for encryption and decoding are not the same, so this is an asymmetric encryption algorithm.

Digital certificates

If you mention HTTPS, you will hear that you need a certificate to deploy, so what is a certificate?

Because the internet is unsafe, the public key is also a part of the information, there will be a risk of tampering. So the introduction of the Internet authority-CA institutions, also known as Certificate Authority (Certificate Authority) institutions, the browser will be built into these "trusted Root Certification Authorities" (that is, CAs).

Service end to the authority of the identification of the CA institutions to apply for digital certificates, CA institutions verified the site, the site will be entered into the internal list, using a Hash of the server to generate a summary of some relevant information, and then the CA agency with its own private key, the service side of the public key and related information encrypted together, A digital certificate is then issued to the server requesting the certificate, which is used by other clients (such as browsers) to authenticate the public key of the site.

Client through the server issued by the certificate, find the corresponding CA, and then to the CA to verify that the certificate is valid, after the CA authentication passed, issued the service side of the public key.

Because the CA is authoritative and trustworthy, the client (browser) trusts the CA, and the CA trusts the authenticated server, so the client (browser) trusts the server, which is the trust chain (Chain of trusts).

A CA-issued digital certificate typically contains this information:

Simply put: to ensure that the public key is secure, the public key is verified by a digital certificate.

Encrypted communication

A complete HTTPS request should look like this:

1. The client (browser) initiates an HTTP request, requests a connection to the server, sends a supported cryptographic communication protocol (and version), and generates a random number that is subsequently used to generate a "conversation key".
2. The server confirms the encrypted communication protocol (and version) and also generates a random number, which is then used to generate the "conversation key" and send the CA-issued digital certificate together to the client.
3. After the client receives the digital certificate, it detects the built-in trusted root certification authorities to see if the public key that unlocks the digital certificate is in.
4. If the public key of the digital certificate is unlocked, it is used to solve the digital certificate, get the correct server public key, and generate a random number for the server public key encryption and send to the server.
5. At this time, the local and server simultaneously three random number, according to the agreed encryption method to encrypt, each generation of the session using the same "session key."
6. Here, the authentication phase is complete, the data transfer from asymmetric encryption to symmetric encryption (because of the performance), the next all the data transfer is transmitted using the HTTP protocol, but using the "session key" to encrypt the content.

See:

Reprint from HTTP to HTTPS