This paper is participating in theNetwork protocols must be known and must be known”Essay campaign
It would be better to read this article on network protocol HTTP first and then this one. If not, skip it.
For additional information about network protocols, go to the Network Protocol Supplement here.
What is the HTTPS
HTTPS is the secure version of HTTP, which establishes SSL and TLS encryption layers over HTTP and encrypts transmitted data. It is now widely used for security-sensitive communications on the World Wide Web, such as transaction payments.
HTTPS provides the following functions:
(1) Encrypt the data and establish an information security channel to ensure the data security in the transmission process;
(2) Carry out real identity authentication to the website server.
We often use HTTPS to communicate on Web login pages and shopping checkout screens. When using HTTPS for communication, use https:// instead of http://. In addition, when a browser visits a Web site with valid HTTPS communication, a lock symbol appears in the browser’s address bar. The display of HTTPS varies from browser to browser.
SSL has been released in three major versions before it was standardized into a third major version, TLS (Transport Layer Security), and was adopted as version 1.0, TLS1.0 = SSL3.1, to be exact.
Why HTTPS?
We know before HTTP2.0, HTTP transmission data are plaintext transmission, HTTP2.0 / HTTP3.0 uses binary frame data, so in every link of transmission, data may be stolen or tampered with by a third party, specifically, HTTP data through the TCP layer, It then passes through WIFI routers, carriers and target servers, all of which can be picked up and tampered with by middlemen, often referred to as man-in-the-middle attacks.
HTTPS encrypts the data on the server/client and decrypts the data on the client/server. In this way, the data can be protected. Although it has been attacked, it also plays a certain role in protection, and the security is getting higher and higher.
TLS1.2
TLS1.2 is actually a very complicated process.
TLS1.2 using RSA connection
Symmetric encryption
Symmetric encryption: encryption and decryption using the same key. If used to encrypt data, packet capture can directly capture the key, so it is not secure.
Asymmetric encryption
Asymmetric encryption: If both A and B keys are available, only B can be used to decrypt the packets encrypted with A, and otherwise, only A can be used to decrypt the packets encrypted with B.
When the server returns data to the client, the packet can be captured by the public key, and the returned data will be cracked out. Although the public key of the uploaded data is encrypted, the hacker cannot decrypt it, so the efficiency is not high and it is not secure.
A combination of symmetric and asymmetric encryption
To sum up, both symmetric and asymmetric encryption are not secure alone, so combining them together is really a good solution.
When TCP establishes a connection.
The first step
First, the browser sends the list of symmetric encryption suites, the list of asymmetric encryption suites and the client-random random number to the server.
The second step
The server saves the client-random random number, selects the suite of symmetric encryption and asymmetric encryption, generates the service-random random number, and sends the selected encryption suite, service-Random, and public key to the browser.
The third step
The browser saves the public key and generates a random number pre-master, encrypts the pre-master using the public key, and sends the encrypted data to the server. Finally, the server takes out its own private key, decrypts the pre-master data, and returns a confirmation message.
The fourth step
The browser and server now have three identical credentials: client_RANDOM, server_random, and pre-master. Then they use the same symmetric encryption method and these three random numbers to generate the final key.
Step 5
The browser and server then use the same key to communicate, using symmetric encryption.
summary
Pre-master is very secure, because the private key decryption is required to calculate the pre-master, according to statistics can be through exhaustive decryption, but this way decryption is not too difficult.
However, once this method is cracked, the historical information can be viewed, because the private key is unchanged, so to solve this problem, the ECDHE algorithm is used.
TLS1.2 of ECDHE is used
The first step
The Client sends the TLS version number of the Client, the list of encrypted password suite, and the Client Random generated by the Client. We can check the TLS version and password suite in the developer tool’s Security.
The second step
After receiving the Client information, the Server confirms the TLS version number, selects the encryption method for this connection, which is also ECDHE, and saves the Client Random for future use. Then, the Server also generates a Server Random and serves Prams “namely ECDHE public key”. There is also the private key front authentication, CA certificate, used to prove the identity of the server.
The third step
After receiving so much information, the Client saves Server Random, Serve Prams, for convenient use in the future. Then it uses the CA certificate to verify the Server identity and generates Client Params through the encryption method just confirmed. Then it uses the public key of the CA certificate to encrypt. When Client Params is passed to the Server, the Server and Client have Client Random, Server Random, Client Params, and Serve Prams.
The fourth step
Using ECDHE algorithm, Client Params and Server Params as parameters, the Server uses its own private key, and the Client uses its own private key to generate pre-master respectively. Pre-master is the key to security. The ECDHE algorithm is used to ensure that hackers cannot algorithm true pre-masters. This is actually using the discrete logarithm of an elliptic curve, and it’s complicated.
Step 5
After the pre-master is generated, it is just a random number, which is another layer of security. Then the Client and Server use three Random numbers: Client Random, Server Random and pre-master. Using these three as raw materials, using the PRF algorithm, and then signing through the digest algorithm like SHA384, you can generate the Master key for the encrypted session, called “Master Secret”. The hacker can’t get the “pre-master,” so he can’t get the Master key. Three random numbers, plus randomness, make HTTPS connections different every time, so it’s too expensive for hackers to crack.
Step 6
The master key also generates the session key, and so on, based on the master key.
As above, use the AES symmetric encryption algorithm to encrypt the session key for data transmission, since the session key is used to transmit HTTPS data.
What are the encryption methods?
For example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE: used to exchange keys
RSA: asymmetric encryption
AES_128_GCM: Symmetric encryption of message and session keys using 128-bit AES in GCM grouping mode
SHA256: Digest algorithm, use digest algorithm, and then use private key to sign the digest is because asymmetric encryption algorithm is not high efficiency, digest data volume is small and can represent the complete data, the digest signature can achieve the effect of the complete data signature.
summary
ECDHE is the ephemeral Elliptic Curve Diffie-Hellman.
1. Using the ECDHE algorithm can improve security because it can be encrypted forward, each HTTPS connection is a random key.
2. With the ECDHE function, the client can send HTTP packets immediately after the server sends a Finished message to confirm the handshake, saving the time for a return message. This is called “TLS False Start”, which means sending application data before a connection is fully established to improve transmission efficiency.
TLS1.3
TLS1.2 is the protocol of 2008, so in 2018 TLS1.3 was born, TLS1.2 in fact, security, performance are a lot of problems, such as RSA handshake is not secure, connection requires two RTT.
TLS1.3 is also subject to a number of limitations, like HTTP3.0, which need to be considered legacy issues.
So TLS1.3 is backward compatible with TLS1.2.
How is TLS1.3 different from TLS1.2?
compatibility
Due to the problem of device hardening, the new algorithm may not be able to be used, which will lead to HTTPS handshake failure. TLS1.3 added the identification mode that can automatically degrade TLS1.2 for better compatibility. If TLS cannot determine this field, TLS1.2 is considered.
Handshake Protocol: Client Hello
Version: TLS 1.2 (0x0303)
Extension: supported_versions (len=11)
Supported Version: TLS 1.3 (0x0304)
Supported Version: TLS 1.2 (0x0303)
Copy the codesecurity
Known attacks on TLS1.2 are BEAST, BREACH, CRIME, FREAK, LUCKY13, POODLE, ROBOT.
Therefore, TLS1.3 removes and replaces some insecure algorithms.
- The pseudo-random number Function is upgraded from PRF to HKDF (HMAC-based extract-and-expand Key Function).
- Explicitly disallow compression in recording protocols; RC4 and DES symmetric encryption algorithms were abolished.
- Abolish ECB, CBC and other traditional grouping modes; MD5, SHA1 and SHA-224 digest algorithms were abolished.
- RSA, DH key exchange algorithms and many named curves were abolished.
In the end, only the five cryptosuite algorithms remain
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_CHACHA20_POLY1305_SHA256
performance
TLS1.2 requires 2 RTTS to connect, so it is a very time-consuming operation. Now TLS only needs 1 RTT, or even 0 RTTS, which is conditional and requires pre_shared_key and early_data.
TLS1.3 Connection details
The first step
The Client sends TLS version number, password suite list, and Client Random. Because the server needs to use ECDHE algorithm in advance, the Client sends parameters to it as far as possible. Supported_versions can confirm whether the server can support TLS1.3. Supported_groups is a list of supported_groups curves, key_share is a parameter corresponding to the curve, and the server can obtain the Client Params in TLS1.2 as the parameter in key_share.
The second step
After verifying compatibility with TLS1.3, the Server confirms the password suite to use and passes Server Params back to key_share and signs the private key.
At this time, in fact, all parameters of the Server are complete, using Client Params and Server Params and ECDHE algorithm to calculate the pre-master, and then using HKDF algorithm Master Secret.
Master Secret is then used to derive the session key, which encrypts the server certificate and passes it to the client.
The third step
The client validates the certificate, then uses the same path as in step 2 to generate Master Secret, and the client and server can communicate.
In fact, I also have a question here, the client authentication certificate is decrypted by the session key, I still need to study how to decrypt.
summary
HTTPS is not a new protocol. It establishes a security layer between HTTP and TCP transmission and uses symmetric encryption and asymmetric secret authentication combined with digital certificate authentication to greatly improve the security of transmission.
Digital Certificates (CA Digital Certificates)
Although the combination of the two encryption methods can achieve a good encryption transmission, but there are still some problems. If a hacker uses DNS hijacking, replacing the target address with the address of the hacker’s server, and then creating a public and private key, the hacker can still carry out data transmission. The browser user, on the other hand, has no idea that he is accessing a dangerous server.
HTTPS digital certificate authentication step, the purpose is to let the server prove its identity.
Bank transfer sometimes also need to verify the identity of the client, so it is through U shield to install a certificate to the operating system, to prove that its current environment is safe.
How do I apply for a certificate?
Step 1: The website developer fills in the website public key, site information, company information and other information and submits it to the CA organization.
Step 2: CA organization will check the authenticity of relevant content; After approval, the CA takes out its own private key and performs a series of operations on the content of the form, including hashing the plaintext data to get a summary of the information, encrypting the summary of the information using the CA’s private key to get a digital signature, and finally writing the digital signature on the form and returning it to the geek. This completes the application for a digital certificate.
Such a CA digital certificate, containing the public key, basic website information, CA digital signature.
How does a browser verify a certificate?
Now that you have the certificate and you can apply it to HTTPS, the server sends it to the browser. How does the browser authenticate the server?
The browser needs to verify the validity period of the certificate, whether the certificate is revoked by a CA, and whether the certificate is issued by a valid CA.
Validity verification
It can be verified against the basic information
Whether the certificate is revoked by the CA
You can verify whether the Certificate is Revocation by downloading Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP).
Check whether the certificate is issued by a valid CA
Step 1: The digital certificate contains the public key and basic information of the website, and the Hash algorithm is used to obtain the summary of the information.
Step 2: provide the public key in CA’s digital certificate to the CA digital signature in the website’s digital certificate, because it has been said that the CA certificate signature is the CA institution to take out the private key encryption, that is, the signature is completed, so now use the public key decryption can get the information summary.
Step 3: Determine whether the abstracts in step 1 and Step 2 are equal or not. If they are equal, they are considered to be issued by the issuing agency.
This raises the question of whether the CA’s digital certificate can be trusted.
We know that the second digest is decrypted using the CA’s public key. Is the CA’s digital certificate that it uses legitimate?
Digital certificate chain
The CA (Root CAs)
Need to pass WebTrust international security audit certification, currently only two associations can issue, AICPA (American Institute of Certified Public Accountants) and CICA (Canadian Institute of Certified Public Accountants) jointly formulated security audit standards, Mainly on the Internet service provider’s system and business operation logic security, confidentiality, a total of seven items of nearly rigorous examination and authentication. Only after the WebTrust authentication is passed, the root certificate can be pre-installed in mainstream operating systems and become a trusted authentication authority.
Intermediate CA Intermediates (CAs)
An intermediate CA can become a trusted intermediate CA only after being authenticated by the root CA certificate, and then the intermediate CA can authenticate the intermediate CA. In this way, a tree is formed, called a certificate certificate chain.
To solve this problem, only the local operating system can authenticate. As long as the root CA certificate is found, the DIGITAL certificate of the CA is considered legitimate.
If you don’t understand anything, or if there are any inadequacies or mistakes in my article, please point them out in the comments section. Thank you for reading.
“Browser Working Principles and Practices”
Perspective HTTP protocol — Chrono
MDN