Preface
Before talking about HTTPS, let's talk about what HTTP is. HTTP is a protocol we usually use when we browse the web. The data transmitted by the HTTP protocol is unencrypted, that is, in plain text, so it is very insecure to use the HTTP protocol to transmit private information. In order to ensure that these private data can be encrypted and transmitted, Netscape designed the SSL (Secure Sockets Layer) protocol to encrypt the data transmitted by the HTTP protocol, thus HTTPS was born. The current version of SSL is 3.0, which is defined in RFC 6101 by IETF (Internet Engineering Task Force). After that, IETF upgraded SSL 3.0, so TLS (Transport Layer Security) 1.0 appeared, which was defined in RFC 2246. In fact, our current HTTPS is the TLS protocol, but because SSL appeared earlier and is still supported by current browsers, SSL is still synonymous with HTTPS, but both TLS and SSL are the last century. The last version of SSL is 3.0. In the future, TLS will inherit the excellent pedigree of SSL and continue to provide encryption services for us. The current version of TLS is 1.2, which is defined in RFC 5246 and has not been widely used yet ()
Concept can refer to Encyclopedia
http://baike.baidu.com/link?url=M8pBu1j_22f0PW6izvAOCTjhepyRcT320U9LDmjyzb586OYS_aBALxfqIGVca1V-8MJeSl3bTUEOThMuwpamPK
HTTPS authentication principle
Before Https actually requests data, it will handshake with the service several times to verify each other's identity. The following figure is an example of the
verification process
Note: The serial number written in the text does not correspond to the figure but the process is corresponding
1. The client initiates an https request and sends a series of Cipher Suite (Key Algorithm Suite, referred to as Cipher) supported by itself to the server
2. The server, after receiving all the Cipher from the client, compares it with its own support. If it does not support it, the connection will be disconnected. Otherwise, an encryption algorithm and HASH algorithm will be selected from it.
The certificate returned to the client in the form of a certificate also contains the expiration date of the website of the public key issuing authority and so on.
3. After receiving the response from the server, the client will do the following things
Verify the legitimacy
of the certificate. Whether the organization issuing the certificate is legal and expired, whether the website address contained in the certificate is consistent with the address being accessed, etc.
After the certificate is verified, a small lock will be added to the address bar of the browser (the prompt of each browser is different after verification is passed, so we will not discuss it)
Generate a random password
If the certificate is verified, or the user accepts an untrusted certificate, the browser will generate a string of random numbers and then encrypt it with the public key in the certificate.
HASH handshake information
Use the initially agreed HASH method to take the HASH value of the handshake message, then encrypt the "handshake message + handshake message HASH value (signature)" with a random number and send it to the server together
The reason why the HASH value of the handshake message is taken here is mainly to make a signature of the handshake message to verify that the handshake message has not been tampered with during transmission.
4. The server gets the ciphertext sent from the client, uses its private key to decrypt the handshake message, takes out the random number password, and then uses the random number password to decrypt the handshake message and the HASH value, and compare it with the passed HASH value for confirmation Is it consistent?
Then use a random password to encrypt a handshake message (handshake message + HASH value of the handshake message) to the client
5. The client uses a random number to decrypt and calculate the HASH of the handshake message. If it is consistent with the HASH sent by the server, the handshake process ends at this time. After that, all communication data will be performed by the random password generated by the previous browser and using a symmetric encryption algorithm. encryption
Because this string of keys is only known by the client and server, it is impossible to decrypt the data even if the intermediate request is intercepted, thus ensuring the security of communication
Asymmetric encryption algorithm: RSA, DSA/DSS In the process of mutual authentication between the client and the server, symmetric encryption is used.
Symmetric encryption algorithm: AES, RC4, 3DES. After the client and the server pass the mutual authentication, a random number is used as the secret. When the key is the symmetric encryption
HASH algorithm: MD5, SHA1, SHA256 When confirming that the handshake message has not been tampered with
How does the client verify the validity of the certificate?
- Verify that the certificate is within the validity period.
The certificate returned by the server will contain the validity period of the certificate, and the expiration date can be used to verify whether the certificate has expired
- Verify that the certificate has been revoked .
The revoked certificate is invalid. There are two methods for verifying revocation: CRL (Certificate Revocation List) and OCSP (Online Certificate Check).
After the certificate is revoked, it will be recorded in the CRL, and the CA will periodically issue the CRL. The application can rely on the CRL to check whether the certificate has been revoked.
CRL has two shortcomings. One is that it may be very large and downloading is very troublesome. For this situation, there is an incremental CRL scheme. Second, there is a lag. Even if the certificate is revoked, the application can only find out after the latest CRL is released.
Incremental CRL can also solve part of the problem, but it has not completely solved it. OCSP is an online certificate status checking protocol. The application sends a request according to the standard to query a certain certificate, and then the server returns the certificate status.
OCSP can be considered instant (there may be a certain delay in actual implementation), so there is no disadvantage of CRL.
- Verify whether the certificate is issued by a higher-level CA.
All trusted root certificates are reserved in windows. The browser can view the trusted root certificates, and it can naturally verify whether the certificate of the web server is issued
by these trusted root certificates or the secondary certificate authority of the trusted root certificate (The root certificate authority may be authorized to the lower intermediate certificate authority, and then the intermediate certificate authority will issue the intermediate certificate.)
When verifying the certificate, the browser will call the system's certificate manager interface to check all the certificates in the certification path. Only when all certificates in the path are trusted, the result of the entire verification is trusted
How does mobile phone grab HTTPS request data
When the site is converted from HTTP to HTTPS, it is more secure, but sometimes it is troublesome to look at the online request data to solve the problem. Because it is an HTTPS request, even if you intercept it, it is encrypted data, which is meaningless.
Is there a solution? The answer is yes! Next, here is an example tutorial to teach you how to view HTTPS request data
First, you need to install Fiddler to intercept requests and issue https certificates
Fiddler root certificate export
Export according to the operation in the figure, and then change the suffix of the exported root certificate "FiddlerRoot.cer" to "crt" "FiddlerRoot.crt" because the mobile phone cannot directly install the certificate in cer format
Certificate installation
Move the certificate to the physical directory of a certain website in the local IIS, and then access the directory of the certificate in the mobile browser, such as: "192.168.0.102:8001/FiddlerRoot.crt"
as shown in the figure
At this time, the phone will prompt to install the root certificate. In fact, it is very dangerous to install an untrusted root certificate. If you install some phishing websites or harmful root certificates, all certificates under the root certificate will be verified. Passed,
as long as the certificate under the root certificate is installed on any phishing net website, there will be no warning prompt.
It is likely to cause the user to have property damage. Therefore, when installing the root certificate, the mobile phone system will ask you to enter the lock screen password to ensure that it is your own operation.
The installation process is as follows
Fiddler's root certificate names all indicate that it is an untrusted root certificate
The installation is complete
Grab the HTTPS request of the mobile phone through Fiddler
The default listening port of Fiddler is 8888. Set the Http proxy of the mobile phone’s WiFI to the address of the local Fiddler as shown in the figure below.
All requests on the mobile phone will pass through Fiddler first, and then Fiddler will be forwarded to the target server.
Note: Wired and wireless are usually not in the same network segment in the router at home, which will cause Fiddler to be unable to capture the mobile phone's package. You need to manually set the routing, you can Baidu by yourself
After the proxy is set up, you can start to capture the content of the Https request. As shown in the figure
, the default port number of Https is "443". It can be seen that the red box is the request before the root certificate is installed, and a small lock is added. The request records are all grayed out.
After the certificate is installed, everything is normal, and the content of the request can be viewed normally.
Why can I see the Https request content after installing the Fiddler root certificate
To explain this problem, you need to understand the authentication principle of Https at the beginning. To review, first, the client submits the encryption method it supports to the server, and then the server will return a certificate
. Why should I install Fiddler's certificate?
First, because Fiddler acts as a server when the client (mobile phone) sends out an Https request, it needs to return a certificate to the client, but the certificate of Fiddler is not issued by the CA, and the client knows that it is a fake connection as soon as it is verified. It must be broken, what should I do?
Then find a way to make the client trust the server, so install a Fiddler root certificate on the client.
So as long as it is through Fiddler's Https request, it will naturally pass when verifying the root certificate, because you have already trusted the root certificate of Fiddler!
Second, now only the Https authentication of the client (mobile phone) and the pseudo-server of Fiddler have passed, and the data has not yet been retrieved from the real server. At this time, Fiddler will perform HTTPS again with the real server as the client. Verification, and finally after getting the data, it
communicates with the client (mobile phone) as the server. That is to say, the data is encrypted and decrypted twice in one request, once from the mobile phone to Fiddler, and once from Fiddler to the real server.
In the whole process, the mobile phone----"Fiddler----" The server Fiddler acts as the server and the client, so that the data can interact normally. The most important part of this process is the root certificate installed on the mobile phone. !
to sum up
Having written so much, in fact, it is only a part of the basic process of Https. Every step of this is a discipline. For us, we can know the general operation process, and even if we have data in our minds Yes,
Https occupies an important position in the current network data security transmission, and there may not be a better solution to replace Https. In addition, you must be careful not to install uncertain root certificates casually to avoid unnecessary losses.
At the time of writing this article, I have already entered my Spring Festival holiday, and I have already embarked on the train home. If you have any questions, you can reply in the comments. If you have any mistakes, I hope you can point out so as not to mislead others.
Linux, C/C++ technology exchange group: [960994558] I have compiled some good learning books, interview questions from big companies, and popular technology teaching video materials to share in it (including C/C++, Linux, Nginx, ZeroMQ, MySQL) , Redis, fastdfs, MongoDB, ZK, streaming media, CDN, P2P, K8S, Docker, TCP/IP, coroutine, DPDK, etc.), you can add it yourself if you need it! ~
