Current location - Quotes Website - Personality signature - Analysis of HTTPS execution process
Analysis of HTTPS execution process
Use Wikipedia's explanation:

Hypertext Transfer P Protocol Secure (abbreviated as https) is a transport protocol used for secure communication through computer networks. HTTPS communicates over HTTP, but uses SSL/TLS to encrypt packets. The main purpose of HTTPS development is to provide authentication for the website server and protect the privacy and integrity of the exchanged data. This protocol was first proposed by Netscape in 1994, and later extended to the Internet.

Historically, HTTPS connection was often used for transaction payment on the World Wide Web and transmission of sensitive information in enterprise information systems. From the end of 2000 to the beginning of 20 10, HTTPS was widely used to ensure the authenticity of various types of web pages, protect accounts and protect the privacy of users' communication, identity and web browsing.

In addition, there is a secure HTTP transmission implementation of Secure Hypertext Transfer Protocol (S-HTTP), but the wide application of HTTPS has become a de facto secure HTTP transmission implementation, and S-HTTP has not been widely supported.

Ps: Looking through the data, I found that the principle of S-HTTP is that every data interaction is RSA asymmetric encryption. Compared with HTTPS, S-HTTP encrypts the interaction of a single transaction, while HTTPS encrypts the communication layer. I think efficiency and universality may also be a major factor in deciding to adopt HTTPS instead of S-HTTP in the market.

The T ransport L ayer S ecurity Protocol (T RAN Sport Layer Security, abbreviated as TLS) and its predecessor, S ecure S ockets L ayer (abbreviated as SSL), are a security protocol, which aims to provide security and data integrity for Internet communication. When Netscape launched its first version of web browser-Netscape Navigator in 1994, it introduced the HTTPS protocol and used SSL for encryption, which is the origin of SSL. IETF standardized SSL, and published TLS 1.0 standard document (RFC 2246) in 1999. Then TLS 1. 1(RFC 4346, 2006), TLS 1.2(RFC 5246, 2008) and TLS 1.3(RFC 8446, 20 18) were published. This protocol is widely used in browser, e-mail, instant messaging, VoIP, network fax and other applications. Many websites, such as Google, Facebook and Wikipedia, also use this protocol to create secure connections and send data. At present, it has become an industrial standard for secure communication on the Internet.

SSL includes a recording layer and a transport layer, and the protocol of the recording layer determines the encapsulation format of data in the transport layer. The transport layer security protocol uses X.509 authentication, then uses asymmetric encryption algorithm to authenticate the communication party, and then exchanges symmetric keys as session keys. The session key is used to encrypt the information exchanged between the two communication parties, thus ensuring the confidentiality and reliability of the communication between the two applications and preventing the communication between the client and the server application from being eavesdropped by attackers.

It is an electronic document used in public key infrastructure to prove the identity of the public key owner. This file contains public key information, owner identity information (subject) and digital signature of digital certificate authority (issuer) to ensure that the overall content of this file is correct. With this file, the owner can identify himself to the computer system or other users, so that the other party can gain trust and authorize access to or use some sensitive computer services. Computer systems or other users can verify the contents of the certificate through some programs, including whether the certificate is expired and whether the digital signature is valid. If you trust the issuer, you can trust the key on the certificate and communicate reliably with the owner with public key encryption.

In short, the certificate authority digitally signs the public key of the person (or organization) who needs to be authenticated with its own private key to generate a certificate, that is, the essence of the certificate is to digitally sign the public key.

People trust the digital certificate authority's root certificate and its public key authentication to use public key encryption to issue digital signatures, forming a trust chain architecture, which has been implemented in TLS and widely used in HTTPS, SMTPS of the World Wide Web and STARTTLS of e-mail. The current standard in the industry is X.509[2] formulated by the Telecommunications Standardization Department of the International Telecommunication Union, which is detailed in RFC 5280 issued by IETF.

X.509 is the format standard of public key certificate in cryptography. X.509 certificate is used in many network protocols including TLS/SSL, and also in many offline application scenarios, such as electronic signature service. X.509 certificate contains public key, identity information (such as network host name, organization name or personal name, etc. ) and signature information (which can be signed by certificate authority CA or self-signed). For a certificate signed by a trusted certificate authority or verified by other means, the owner of the certificate can use the certificate and the corresponding private key to create secure communication and digitally sign the document.

In addition to the functions of the certificate itself, X.509 also comes with a certificate revocation list and a certificate validity verification algorithm, which is used from the certificate authority that finally signed the certificate to the final trusted point.

X.509 is a set of certificate standards defined by ITU-T standardization department based on their previous ASN. 1

Hash, commonly translated as hash, hash, or transliterated as hash, is to convert an input of any length (also called pre-mapped image) into an output of fixed length through a hash algorithm, and this output is a hash value.

Hash algorithm is also called hash algorithm. Although hash algorithm is called algorithm, it is actually more like an idea. Hash algorithm has no fixed formula, as long as it conforms to the idea of hash, it can be called hash algorithm.

Features: Can't reverse crack, can be used to check uniqueness.

Using the encryption method of single-key cryptosystem, information can be encrypted and decrypted simultaneously with the same key. This encryption method is called symmetric encryption.

Common: AES DES 3DES Features: High efficiency

A pair of keys, a public key and a private key, the data encrypted by the public key can only be decrypted by the private key, and the data encrypted by the private key can only be decrypted by the public key. To ensure the security of asymmetric encryption is a factorization of the largest integer (the mathematical realization is based on coprime, Euler function, euler theorem, modular inverse, without detailed explanation), so wiki says:

Common: RSA features: low efficiency and long time consuming.

There are the following hidden dangers in using http interactive information:

Personally, due to the insecurity of HTTP, a secure protocol is urgently needed as a supplement. HTTPS is based on the HTTP protocol, and adds the Transport Layer Security Protocol (TLS/SSL), which is a protocol standard, and x.509 is an implementation of this protocol standard. X.509 uses encryption-related hash algorithm, symmetric encryption algorithm and asymmetric encryption algorithm.

1.clientHello First of all, the https request is based on http, that is, tcp, so we need to establish the tcp three-way handshake first, let's not talk about this. Then the tcp handshake is followed by the SSL handshake, which is the client hello message in the figure. The client sends the latest TLS version, algorithm combination set and many other auxiliary information to generate a random number A. See the following figure for details:

It can be seen that the random number is a GMT UNIX time plus a string of random bytes, and there are 26 cipher groups.

2. After receiving these messages, the server hello server selects the lower one as the return, selects an appropriate combination from the algorithm combination set, and then generates a random number b, which is packaged as serverhello and returned to the client. The content is as shown in the figure:

The cipher suite algorithm combination is selected here.

3.Certificatetie, server hellodone The server will tell its certificate information to the client (certificate) and the information of key update to the client (ServerkeyExchange) after choosing a good communication strategy, and then it's up to you, that is to say, all messages will be sent to you, and my hello will be over (server Hellodone).

4. After receiving the information in steps 2 and 3, the client first verifies whether the certificate is legal, including its issuing authority, domain name matching, limited period, etc. This specific process will not be explored, as long as you know these steps.

5. After the certificate is verified, the random number C 1 is generated, and then the public key in the certificate content is encrypted by the asymmetric encryption algorithm selected by the server to obtain C2.

6. Generate a D from the first three random numbers A, B, C 1 by a pseudo-random function. Attention! This is the encryption key that http really uses! ! ! .

7.d Generate a key group with pseudo-random function again, including 6 keys, which are assumed to be P 1, P2, P3, P4, P5 and P6.

8.ClientKeyExchange. Inform the server of the secret key and send C2 calculated in step 5 to the server.

9. After the client sends the ClientKeyExchange, calculate the hash values of all messages that interacted with the server before, assuming that it is client_hash 1, and encrypt it with one of the P 1 obtained in step 7, and the result is E. ..

10. After receiving C2, the server decrypts C2 with private key combined with asymmetric algorithm to get C 1.

1 1. The same server generates d (the final encryption key! ! ! ), and then get the secret group key (P 1-P6) from D. Because all the algorithms involved here are the same, the obtained secret key is the same.

12. The hash value of all messages interacting with the client before the server calculation is assumed to be server_hash2. You may find that 1 1 and 12 are the same as those of client 6, 7 and 9, but the encryption process of P 1 in 9 is different.

13. At this point, the client will send ChangeCipherSpec message and EncryptedHandshakeMessage message to inform the server that it will use the selected encryption policy for communication next, and pass the e in step 9 to the server. (The sequence of steps here is only for better understanding. In fact, the two lines process information independently, so the order cannot be guaranteed. )

14. At this time, the client will calculate the hash value of the previous handshake message again and get the result of client_hash2.

15. After the server receives the e brought by the EncryptedHandshakeMessage, it decrypts the e with p 1 1. Since the encryption algorithm is the same as P 1, client_hash 1 is restored here, and then it is the same as step 12.

16. The server hashes the previous message again to get the server _ hash, encrypts it with P2, and the result is f, and then transmits it to the client through ChangeCipherSpec-Encrypted Handshake Message.

17. After receiving the message sent by the server, the client decrypts F according to P2 to get server_hash2. If it is consistent with client_hash2, it is considered that the previous interaction process is correct and understood by the other party. At this point, the whole handshake process is over, and the subsequent http datagrams will be encrypted and transmitted through the previously determined encryption policy and encryption key D. ..

Summary: In fact, in the end, we found that the final encryption key D was not passed directly in the whole handshake process, but some algorithm strategies and some parameters for generating D were exchanged, which would be safer. If the data is transmitted directly, the process will be completed by the client. If something goes wrong in the middle, the server will trust the data sent by the client unconsciously, which may lead to problems. Therefore, only the transmission strategy and parameters are adopted, and both parties participate in it, which is safe and secure. Post a picture of the whole process:

Mainly to prevent replay attack. Replay attack means that an attacker sends a data packet that the destination host has received to deceive the system, which is mainly used in the identity authentication process and destroys the correctness of authentication.

When a browser client accesses the same https server, it is not necessary to conduct a complete TLS handshake every time, because a complete TLS handshake involves the identity of the authentication server (digital certificate), requires a lot of asymmetric encryption/decryption operations, and also requires a pseudo-random function PRF. The session key is derived from Pre-Master Key, Server Random Number and Client Random Number * *. Asymmetric encryption algorithm RSA/DSA consumes CPU resources very much.

In order to overcome this difficulty, the server maintains a structure with session ID as the index, which is used to temporarily store the session key and share it with the browser when TLS handshakes.

When the browser reconnects to the https server, in the TLS handshake stage, the server displays its session ID, which is used as an index to obtain the session key owned by the browser * * *, and the user traffic can be directly encrypted/decrypted by using the session key.

This avoids a lot of power sum exponent calculation.

Of course, if the server does not find the session ID, the negotiation of TLS security parameters between the two parties will follow the normal process.

Use charles to analyze the usage of session ID. Suppose there is a request that the server allows the use of Session ID, then there will be the following process:

1. The client initiates an HTTPS request to the server.

2.Charles intercepts the client's request and pretends that the client sends a request to the server.

3. The server returns the server's CA certificate to the "client" (actually Charles).

4.Charles intercepts the response of the server, obtains the public key of the server certificate, and then makes a certificate by himself, replaces the server certificate and sends it to the client. (At this step, Charles obtains the public key of the server certificate. )

5. After receiving the certificate from the "server" (actually Charles), the client generates a symmetric key, which is encrypted with Charles' public key and sent to the "server" (Charles).

6.Charles intercepts the client's response, decrypts the symmetric key with his own private key, then encrypts it with the public key of the server certificate and sends it to the server. (At this step, Charles gets the symmetric key.

7. The server decrypts the symmetric key with its own private key and sends a response to "Charles".

8.Charles intercepts the server's response, replaces it with his own certificate and sends it to the client.

At this point, the connection is established, Charles obtains the public key of the server certificate and the symmetric key negotiated between the client and the server, and then he can decrypt or modify the encrypted message.

(Core point: charles has generated his own set of public key, private key and his own certificate. Because his certificate cannot be verified, he needs the active authorization of the client. Charles can completely interact with the server instead of the client after the client is authorized. The interaction with the server is encrypted with the server's public key, and the interaction with the client is decrypted with Charles's own private key. )