Previous: Disadvantages of Http
In this article, we will describe in detail what is Https
1. What is HTTPS
HTTPS = HTTP + encryption + authentication + integrity protection
If unencrypted plaintext is used during HTTP protocol communication, such as entering a credit card number in a Web page, if the communication line is tapped, the credit card number is exposed.
In addition, for HTTP, no matter the server or the client, there is no way to confirm the communicating party. Because it is very likely that the actual communication is not with the originally intended communication party. And it is also necessary to consider the possibility that the received message has been tampered with during the communication.
In order to solve the above problems uniformly, it is necessary to add encryption processing
and . We call HTTP with added encryption and authentication mechanism HTTPS (HTTP
Secure).
HTTPS communication is often used in web login pages and shopping checkout interfaces. When using HTTPS communication, use https:// instead of http://. Also, when the browser accesses a Web site where HTTPS communication is active, a lock mark appears in the browser's address bar. The way HTTPS is displayed varies by browser.
Second, Https is HTTP in an SSL shell
HTTPS is not a new protocol at the application layer. Only the HTTP communication interface is replaced by SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols.
Typically, HTTP communicates directly with TCP. When using SSL, it evolved to communicate with SSL
first , and then SSL communicated with TCP. In short, the so-called HTTPS is actually
HTTP in the shell of the SSL protocol.
With SSL, HTTP has the encryption, certificate, and integrity protection of HTTPS.
SSL is a protocol independent of HTTP, so not only HTTP protocol, but also other protocols such as SMTP and Telnet running at the application layer can be used with the SSL protocol. It can be said that SSL is the most widely used network security technology in the world today.
3. Symmetric key encryption
Before explaining SSL, let's take a look at encryption methods. SSL uses a form of encryption called public-key cryptography. Also known as symmetric key encryption
In modern encryption methods, the encryption algorithm is public, while the key is kept secret. In this way the security of the encryption method is maintained.
Keys are used for both encryption and decryption. The password cannot be decrypted without the key, and conversely, anyone who has the key can decrypt it. If the key is obtained by the attacker, the encryption will lose its meaning. When encrypting
with a shared key, the key must also be sent to the other party. But how can it be transferred safely? When forwarding keys over the Internet, if the communication is intercepted, the keys could fall into the hands of an attacker and the encryption would be meaningless. There is also a way to securely store the received key.
Fourth, asymmetric encryption (public key encryption, public key and private key encryption)
Public-key encryption uses a pair of asymmetric keys. One is called the private key and the other is called the public key. As the name suggests, the private key cannot be known to anyone else, while the public key can be released at will and available to anyone.
With public key encryption, the party sending the ciphertext uses the other party's public key for encryption, and the other party uses its own private key for decryption after receiving the encrypted information. In this way, there is no need to send the private key for decryption, and there is no need to worry about the key being eavesdropped and stolen by an attacker.
In addition, it is extremely difficult to recover the original message based on the ciphertext and public key, because the decryption process is evaluating the discrete logarithm, which is not easy to do. Taking a step back, if a very large integer can be factored quickly, then there is still hope for password cracking. But it's not realistic with current technology.
5. Https uses hybrid encryption
HTTPS uses a hybrid encryption mechanism that uses both shared-key encryption and public-key encryption. If the keys can be exchanged securely, it is possible to consider using only public key encryption for communication. But public-key encryption is slower to process than shared-key encryption.
Therefore, we should make full use of their respective advantages and combine various methods for communication. The public key encryption method is used in the key exchange link, and the shared key encryption method is used in the subsequent stage of establishing communication and exchanging messages.
6. A certificate proving the public key
Unfortunately, there are still some problems with public key encryption. That is, there is no way to prove that the public key itself is the genuine public key. For example, when preparing to establish communication with a server under public key encryption, how to prove that the received public key is the original expected public key issued by the server. Perhaps during the transmission of the public key, the real public key has been replaced by the attacker.
In order to solve the above problems, public key certificates issued by a digital certificate authority (CA, Certificate Authority) and its related authorities can be used. The digital certificate authority is in the position of a third-party authority trusted by both the client and the server. VeriSign (VeriSign) is one of the very famous digital certificate certification agencies.
Let's introduce the business process of the digital certificate certification authority. First, the operator of the server submits an application for a public key to the digital certificate certification authority. After identifying the identity of the applicant, the digital certificate certification authority will digitally sign the applied public key, then distribute the signed public key, and put the public key into the public key certificate and bind it in the public key certificate. Together.
The server will send the public key certificate issued by the digital certificate authority to the client for public key encryption communication. Public key certificates can also be called digital certificates or simply certificates. The client receiving the certificate can use the public key of the digital certificate authority to verify the digital signature on that certificate. Once the verification is passed, the client can know two things:
First, the authentication server's public key is a real and valid digital certificate certification authority.
Second, the server's public key is trustworthy.
Here the public key of the certificate authority must be securely transferred to the client. When using a communication method, it is very difficult to transfer it securely. Therefore, when most browser developers release the version, they will implant the public key of the commonly used certification authority in advance.
Seven, EV SSL certificate that can prove the authenticity of the organization
One function of the certificate is to prove whether the server on the other side of the communication is standardized, and the other function is to confirm whether the enterprise operating behind the server of the other party actually exists. A certificate with this feature is an EV SSL certificate (Extended Validation SSLCertificate).
EV SSL certificates are certificates issued based on international standard certification guidelines. It strictly stipulates the policy of confirming the authenticity of the operating organization, and therefore, the certified Web site can obtain a higher degree of recognition.
The background color of the browser's address bar of a Web site that holds an EV SSL certificate is green, which is visually recognizable at a glance. Also, the name of the organization recorded in the SSL certificate and the name of the certification authority that issued the certificate are displayed on the left side of the address bar.
The original intention of the above mechanism is to prevent users from being attacked by phishing (Phishing), but in terms of effect, there is a question mark. Many users may not have knowledge about EV SSL certificates, so they don't pay much attention to it.
Eight, to confirm the client certificate of the client
Client certificates can also be used in HTTPS. The client authentication is performed with the client certificate, which proves that the counterparty the server is communicating with is always the expected client, and its function is exactly the same as that of the server certificate.
But there are still several issues with client certificates. One of the problem points is the acquisition and issuance of certificates.
To obtain a certificate, the user has to install the client certificate by himself. However, since the client certificate is purchased for a fee, and each certificate corresponds to each user, it means that a fee equal to the number of users needs to be paid. In addition, getting users with different knowledge levels to install certificates on their own is fraught with challenges.
The status quo is that very secure certificate authorities can issue client certificates but only for special purpose business. For example, those services that can support client certificate expenses. For example, the bank's online banking uses client certificates. When logging in to the online banking, the user is not only required to confirm the input of ID and password, but also requires the user's client certificate to confirm whether the user accesses the online banking from a specific terminal.
Another problem with the client certificate is that, after all, the client certificate can only be used to prove the actual existence of the client, and cannot be used to prove the real validity of the user himself. That is to say, as long as you have the right to use the computer with the client certificate installed, you also have the right to use the client certificate.
Nine, Https communication mechanism
Step 1: The client starts SSL communication by sending a Client Hello message. The message contains the specified version of SSL supported by the client, and the list of encryption components (Cipher Suite) (encryption algorithm used and key length, etc.).
Step 2: When the server can communicate with SSL, it will reply with a Server Hello message. As with the client, the SSL version and encryption components are included in the message. The server's cryptographic component content is filtered from the received client-side cryptographic components.
Step 3: Then the server sends a Certificate message. The message contains the public key certificate.
Step 4: Finally, the server sends a Server Hello Done message to notify the client that the initial phase of the SSL handshake negotiation is over.
Step 5: After the first handshake of SSL, the client responds with a Client Key Exchange message. The message contains a random cipher string called Pre-mastersecret used in communication encryption. The message has been encrypted with the public key from step 3.
Step 6: Then the client continues to send the Change Cipher Spec message. This message will prompt the server, and the communication after this message will be encrypted with the Pre-master secret key.
Step 7: The client sends a Finished message. This message contains the overall check value of all messages connected so far. Whether the handshake negotiation is successful or not depends on whether the server can correctly decrypt the message.
Step 8: The server also sends a Change Cipher Spec message.
Step 9: The server also sends a Finished message.
Step 10: After the finished message exchange between the server and the client is completed, the SSL connection is established. Of course, the communication is secured by SSL. From here, the communication of the application layer protocol starts, that is, the HTTP request is sent.
Step 11: Application layer protocol communication, that is, sending HTTP response.
Step 12: Finally disconnected by the client. When disconnected, send a close_notify message. Some omissions are made in the above figure. After this step, a TCP FIN message is sent to close the communication with TCP.
In the above process, a message digest called MAC (MessageAuthentication Code) is attached when the application layer sends data. The MAC can check whether the packet has been tampered with, thereby protecting the integrity of the packet.
Below is an illustration of the entire process. The diagram illustrates the entire process of establishing HTTPS communication from using only the server-side public key certificate (server certificate).
X. SSL and TLS
HTTPS uses two protocols, SSL (Secure Socket Layer) and TLS (Transport Layer Security).
SSL technology was first pioneered by browser developer Netscape Communications, which developed the version before SSL3.0. The current leadership has been transferred to the hands of the IETF (Internet Engineering Task Force, Internet Engineering Task Force).
The IETF takes SSL3.0 as the benchmark, and later developed TLS1.0, TLS1.1 and TLS1.2. TSL is a protocol developed on the basis of SSL, and is sometimes referred to collectively as SSL. The current mainstream versions are SSL3.0 and TLS1.0.
Since the SSL1.0 protocol was found to have problems at the beginning of its design, it was not actually put into use. SSL2.0 was also found to be problematic, so many browsers abolished this protocol version directly.
HTTPS also has some problems, which is that when using SSL, it can be slow to process.
There are two types of SSL slowness. One is that the communication is slow. The other means that the processing speed is slow due to the large consumption of resources such as CPU and memory.
The network load can be 2 to 100 times slower compared to using HTTP. In addition to connecting with TCP and sending HTTP request/response, SSL communication is also required, so the overall processing traffic will inevitably increase.
Another point is that SSL must be encrypted. Both the server and the client need to perform encryption and decryption operations. As a result, it consumes more server and client hardware resources than HTTP, resulting in increased load.
There is no fundamental solution to the slowdown, and we use (dedicated server) hardware like SSL accelerators to improve the problem. The hardware is dedicated for SSL communication, and compared with software, it can improve the computing speed of SSL several times. The SSL accelerator functions only during SSL processing to share the load.
Since HTTPS is so secure and reliable, why don't all Web sites use HTTPS all the time?
One of the reasons is because encrypted communication consumes more CPU and memory resources than plain text communication. If each communication is encrypted, it will consume a lot of resources, and when it is evenly distributed on a computer, the number of requests that can be processed will certainly be reduced accordingly.
Therefore, HTTP communication is used for non-sensitive information, and HTTPS is used to encrypt communication only if it contains sensitive data such as personal information. Especially whenever those Web sites with more traffic are encrypted, the load they bear cannot be underestimated. When encrypting, not everything is encrypted, but only those that require information hiding to save resources.
In addition, wanting to save the cost of purchasing certificates is also one of the reasons.
A certificate is required for HTTPS communication. The certificate used must be purchased from a Certification Authority (CA). Certificate prices may vary slightly depending on the certification authority. Usually, one-year authorization requires tens of thousands of yen (now 10,000 yen is about 600 yuan). Services for which it is not cost-effective to purchase a certificate, as well as some personal websites, may only choose to communicate using HTTP.
above!