1. SSL version Problems
The credit for HTTPS encrypted transmission is TLS. SSL is the predecessor of TLS. The final version of SSL is 3.0, and the latest version of TLS is 1.3.
The encryption function of TLS depends on the public/private key encryption/decryption system.
2. SSL Workflow
1. the user's browser sends the following information to the server.
I. TLS version number
Ii. Random Number: generally a random number of 28 bytes. the random number will be used to generate the final symmetric key.
Iii. session ID:
Here it is null or null. If the browser has connected Amazon.com a few seconds ago, it may continue to use the previous session without re-executing the entire "handshake" process.
Iv. cryptographic algorithms supported by browsers
V. HOST:
SSL handshake before HTTP Transmission
2. the server sends the SSL version number, encryption setting parameters, session-related data, and other necessary information to the browser, and also sends the server certificate to the browser. If the SSL of the configuration server needs to verify the user identity, you must also send a request asking the browser to provide the user certificate.
I. UNIX Timestamp and 28-byte random number. the random number will be used to generate the final symmetric key.
II. A 32-byte session ID.
With it, you do not need to execute a complete handshake process after re-connecting to the server.
Iii. Selected Encryption Algorithm
Example: tlsrsawithrc4128_md5
Indicates that the "RSA" Public Key algorithm is used to verify the certificate and exchange the key. The RC4 encryption algorithm is used to encrypt the data and the MD5 hash algorithm is used to verify the message content.
Iv. Certificate
The content includes: Organization Name, address, server DNS domain name, signature algorithm, signature value, MD5 Value
Third, the client checks the server certificate. If the check fails, the system prompts that an SSL connection cannot be established. If yes, continue
I. Date Detection
Ii. Signature issuer credibility Detection
Iii. Signature Detection
Iv. Site identity detection
4. The client browser generates a pre-master secret for this session and sends it to the server after encrypting it with the server public key.
It is complicated to generate a pre-master secret.
The RSA public key encryption algorithm was proposed by Ronald Rivest, Adi Shamir, and Leonard Adleman in 1977. Both of them were working at the Massachusetts Institute of Technology.
First, select two large prime numbers "P" and "Q" and product them to get "n = p * q ". Next, take a small "E" as the index and use it as the "encryption Index ", the "D" obtained by performing a special Inverse Function Calculation on E is used as the "decryption Index ". Then, make "N" and "E" public, and keep "D" confidential. For "P" and "Q", you can discard them, it can also be kept as confidential as "D. It is really important to remember that "D" and "E" are mutual inversion.
Now, if you have some messages, you only need to translate the bytes of the message into a number of "M". If you want to encrypt the message to form a "ciphertext, this is how you calculate:
C producer me (mod N)
This means that the power of "E" of "M" is obtained first, and then the modulus "N" is applied to it for remainder. For example, 11 Am + 3 hours limit 2 (PM) (mod 12 hours ). The recipient knows (decrypted) "D", and "D" can reverse and restore the encrypted message:
CD lead (me) d lead me * D lead M1 lead M (mod N)
Another interesting thing is that people with "D" can sign a document, in this document, "M" is used to calculate the power of "D" and then the modulus "N" is used to calculate the remainder "S ":
MD ≡ S (mod N)
Know the public encryption Index "E" and module "N ". Now we need to create a random key that cannot be identified by attackers or eavesdroppers. This is not as simple as it sounds. In 1996, researchers found that Netscape navigator1.1 only uses three data sources as the seeds of their pseudo-random number generator (PRNG), which are the current time, process number, and parent process number, although the 48-Byte "pre-master secret" random number is not directly used, it is very important to ensure its privacy.
Fifth, if the server requires customer identification, the client must sign other data and send it together with the client certificate to the server.
6. If the server requires customer identification, check whether the CA that signs the customer certificate is trusted. If the session is not in the Trust List, end the session. If the check succeeds, the server uses its own private key to decrypt the received pre-master secret and uses it to generate the master secret for this session through some algorithms.
Mastersecret = PRF (premaster_secret, "Master secret", ClientHello. Random + serverhello. Random)
"Premastersecret" is sent before the client; "Master secret" uses the ASCII value of a string (for example, "6D 61 73 74 65 72 ..."). Then We splice the random numbers sent by ClientHello and serverhello that we first saw in this article.
PRF is a pseudo-random number function, which is intelligent and defined in the Protocol. It uses the MD5 and SHA-1 hash functions of the hash-based message Verification Code (HMAC) to combine keys, ASCII characters, and the seeds we give. Sends half of the input to each hash function. The reason for its cleverness is that, even in the face of MD5 and SHA-1 vulnerabilities, its attack defense capability is still strong. This process enables self-feedback and continuous loops, and we can generate as many bytes as we need.
According to this process, we obtain the following 48-Byte "Master secret"
7. Both the client and server use this master secret to generate the session key (symmetric key) for this session ). This session key is used to send any messages after the SSL handshake ends. The main reason for doing so is that symmetric encryption is more than an order of magnitude less computation than asymmetric encryption, which can significantly increase the computing speed of both parties' sessions.
Now both parties have "Master secrets", which describes how to generate all the keys required for the session. We need to use the PRF function to create a "Key Block ", then extract the required key from the block:
8. The client notifies the server that messages sent subsequently use this session key for encryption. And notifies the Server client that the SSL handshake has been completed.
9. The server notifies the client that messages sent subsequently use this session key for encryption. The client server is notified that the SSL handshake has been completed.
10. The handshake is over and the session has been established. Both parties use the same session key to encrypt and decrypt the sent and received information respectively.
In SSL communication, asymmetric encryption is used to exchange information so that the server can obtain the symmetric encryption key provided by the browser. Then, the server can use this key to encrypt and decrypt the information during communication. To ensure that messages are not tampered with during transmission, you can encrypt the hash code to ensure information integrity.
SSL process details
