Jmeter interface testing and interface automation testing from entry to proficiency, a full set of project practice! ! !

1. Talking about HTTPS

We all know that HTTP is not a secure transmission, and the HTTPS protocol formed by using the SSL protocol for encryption on the basis of HTTPS is relatively safe. At present, more and more enterprises choose to use the HTTPS protocol to communicate with users, such as Baidu and Google. HTTPS requires a handshake between the client (browser) and the server (website) before transmitting data. During the handshake, the password information for encrypted data transmission between the two parties will be established. There are a lot of information on the Internet, some of which are too obscure and difficult to understand, especially some knowledge of cryptography is required. I did a simple tidying up, removed the complex underlying implementation, and got a macro view of HTTPS from the perspective of understanding the SSL protocol. In a word, HTTPS uses an asymmetric encryption algorithm (such as the RSA algorithm) to generate and exchange the negotiation key, and then uses the negotiation key for symmetric encrypted communication in the subsequent communication process . The principle and process diagram of HTTPS protocol transmission are as follows:

There are 8 steps in total, let's look at each step to see what happened:

In the first step, the client initiates a plaintext request: sending a set of encryption rules it supports and a random number (Random_C) to the server.

The second step, the server's initial response: the server selects a set of encryption algorithms and HASH algorithms from the request sent by the client according to the encryption rules it supports, generates random numbers, and uses its own identity information as a certificate (CA) The form is sent back to the browser. The CA certificate contains information such as the server address, encrypted public key, and certificate issuing authority. At this time, what the server gives to the client includes the encryption rules selected to be used, the CA certificate, and a random number (Random_S).
In the third step, the client does four things after receiving the initial response from the server:
(1) Certificate verification: Verify the validity of the certificate (whether the organization issuing the certificate is legal, whether the website address contained in the certificate is the same as the address being visited consistent, etc.).
(2) Generate password: The browser will generate a string of random number passwords (Pre_master), and encrypt them with the public key in the CA certificate (enc_pre_master) for transmission to the server.
(3) Calculate the negotiation key:
At this point, the client has obtained all the information needed to calculate the negotiation key: two random numbers Random_C and Random_S in plain text and the Pre-master calculated by itself, and calculate the negotiation key enc_key.
enc_key=Fuc(random_C, random_S, Pre-Master) 
(4) Generate handshake information: Use the agreed HASH to calculate the handshake message, and use the negotiated key enc_key and the agreed algorithm to encrypt the message.
In the fourth step, the client sends the data generated in the third step to the server:
there are three pieces of data to be sent here:
(1) The server random number password enc_pre_master encrypted with the public key
(2) The notification sent by the client to the server, "In the future, we will use the agreed algorithm and negotiated key to communicate."
(3) The client encrypts the generated handshake information.
The fifth step, the server receives the data sent by the client to do the following four things: (1) Private key decryption: use its own private key to decrypt the received enc_pre_master and take out the password Pre_master.
(2) Calculate the negotiation key: At this point, the server has obtained all the information needed to calculate the negotiation key: two plaintext random numbers Random_C and Random_S and the Pre-master, and calculate the negotiation key enc_key.
enc_key=Fuc(random_C, random_S, Pre-Master) 
(3) Decrypt the handshake message: Use the negotiation key enc_key to decrypt the handshake message sent by the client, and verify whether the HASH is consistent with the one sent by the client.
(4) Generate a handshake message Use the negotiated key enc_key and the agreed algorithm to encrypt a handshake message and send it to the client.
In the sixth step, the server sends the data generated in the fifth step to the client:
there are two data to be sent here:
(1) The notification sent by the server to the client, "Listen to you, we will use the agreed algorithm and Negotiate key to communicate".
(2) The server encrypts the generated handshake information.

In the seventh step, the client gets the handshake information and decrypts it, and the handshake ends.
The client decrypts and calculates the HASH of the handshake message. If it is consistent with the HASH sent by the server, the handshake process ends.

The eighth step, normal encrypted communication
After the handshake is successful, all communication data will be encrypted and decrypted by the previously negotiated key enc_key and the agreed algorithm.

Here, the client and the server send encrypted handshake messages to each other and verify them. The purpose is to ensure that both parties have obtained the same password, and can encrypt and decrypt data normally, and do a test for the subsequent real data transmission. In addition, the encryption and HASH algorithms generally used by HTTPS are as follows: Asymmetric encryption algorithm: RSA, DSA/DSS Symmetric encryption algorithm: AES, RC4, 3DES HASH algorithm: MD5, SHA1, SHA256 Among them, the asymmetric encryption algorithm is used for encryption during the handshake process For the generated password, the symmetric encryption algorithm is used to encrypt the data actually transmitted, and the HASH algorithm is used to verify the integrity of the data. Since the password generated by the browser is the key to the encryption of the entire data, it is encrypted using an asymmetric encryption algorithm during transmission. The asymmetric encryption algorithm will generate a public key and a private key. The public key can only be used to encrypt data, so it can be transmitted at will, and the private key of the server is used to decrypt the data, so the server will keep its private key very carefully. Prevent leaks.

Two, Fiddler grabs the HTTPS protocol principle

We all know that Fiddler is a good proxy tool that can capture protocol requests for debugging. The principle and configuration of Fiddler's capture of the HTTP protocol are relatively simple. With a little configuration of Fiddler and the client, Fiddler can easily obtain HTTP requests. However, due to the particularity of the HTTPS protocol, to further configure Fiddler, we must first understand how fiddler captures the HTTPS protocol to better understand how to configure fiddler. Fiddler itself is a protocol proxy tool. In the HTTPS schematic diagram in the previous section, all the communication processes between the client and the server are obtained by Fiddler, as shown in the following figure:

We see that Fiddler captures the HTTPS protocol mainly by the following steps:

In the first step, Fiddler intercepts the HTTPS request sent by the client to the server, and Fiddler pretends to be the client to send a request to the server for handshake.

In the second step, the server sends back a response. Fiddler obtains the server's CA certificate, decrypts it with the root certificate public key, verifies the server data signature, and obtains the server CA certificate public key. Then Fiddler forges its own CA certificate, pretending to be the server certificate and passing it to the client browser.

The third step is the same as the operation of the client in the normal process. The client performs certificate verification based on the returned data, generates the password Pre_master, encrypts with the certificate public key forged by Fiddler, and generates the symmetric key enc_key for HTTPS communication.

In the fourth step, the client sends important information to the server, which is intercepted by Fiddler. Fiddler decrypts the intercepted ciphertext with the private key of its forged certificate, obtains and calculates the symmetric key enc_key for HTTPS communication. Fiddler encrypts the symmetric key with the public key of the server certificate and passes it to the server.

The fifth step is the same as the server-side operation in the normal process. The server uses the private key to unlock and establish trust, and then sends an encrypted handshake message to the client.

In the sixth step, Fiddler intercepts the ciphertext sent by the server, decrypts it with a symmetric key, and then encrypts it with the private key of its forged certificate and sends it to the client.

Step 7: After the client gets the encrypted information, it uses the public key to unlock it and verify the HASH. The handshake process is officially completed, and the "trust" is established between the client and the server.

In the subsequent normal encrypted communication process, how does Fiddler act as a third party between the server and the client?

Server—>Client : Fiddler receives the ciphertext sent by the server, decrypts it with the symmetric key, and obtains the plaintext sent by the server. Encrypt it again and send it to the client.
Client -> Server : The client is encrypted with a symmetric key, and after being intercepted by Fiddler, it is decrypted to obtain the plaintext. Encrypt it again and send it to the server. Since Fiddler always has the symmetric key enc_key for communication, the information is transparent to it during the entire HTTPS communication process.

As can be seen from the above, the key to the success of Fiddler's capture of the HTTPS protocol is the root certificate (specifically, Google), which is the starting point of a chain of trust, which is also the reason why Fiddler's forged CA certificate can be trusted by the client and server The essential.
Next, let's see how to set up Fiddler to capture the HTTPS protocol.

3. Fiddler grabs HTTPS settings

Note that the premise of the following operations is that the mobile phone has been able to connect to Fiddler. The configuration process of this part is simple and will not be described in detail. You can refer to: How to connect to Fiddler on a mobile phone .
How to continue to configure Fiddler to capture the HTTPS protocol?
(1) First set up Fiddler: Open the toolbar->Tools->Fiddler Options->HTTPS

Select Capture HTTPS CONNECTs, because we want to use Fiddler to obtain the HTTPS request sent by the mobile client, so select from remote clients only in the middle drop-down menu. Select Ignore server certificate errors below.
(2) Then, install the Fiddler certificate on the phone.
This step is the key to capturing HTTPS requests we analyzed above.
The operation steps are very simple. Open the mobile browser, enter the proxy server IP and port in the browser address, and you will see a page provided by Fiddler.

Then click the FiddlerRoot certificate at the bottom, and then click OK to install to download the Fiddler certificate.
After the download and installation is complete, we use the mobile client or browser to send an HTTPS request, and Fiddler can intercept it, just like intercepting ordinary HTTP requests.

jmeter sends HTTPS request

Word count 652 Read 375 Comment 0 Like 2

Generally speaking, jmeter is a sharp tool for stress testing. Recently, I want to try jmeter and BeanShell for interface testing. Since the login operation is required during the cloud reading interface test, the login request is HTTPS protocol. This requires setting up jmeter.

(1) Set HTTP request

We first right-click to add a thread group, and then continue to right-click to add a controller. Since the login operation is only requested once, we choose the controller only once. Next, right-click to add sampler->HTTP request, and set the HTTP request. The first thing to pay attention to here is the port number. If it is just an ordinary HTTP protocol, it will not be filled by default, but here is the HTTPS protocol, so fill in the port number 443. In addition, fill in "https" here for "protocol". The request body data, since the post data when logging in to Cloud Reading is in the json structure, fill in the Body Data and organize the data with curly brackets. PS: In fact, it should be a post request. I forgot to change the screenshot too soon~


(2) Set Jmeter proxy

The last blog just talked about the HTTPS protocol and the principle of proxy control to send HTTPS requests . We know that the key to successfully sending HTTPS requests is the proxy settings. First of all, we need to add a recording controller in the thread group, otherwise Jmeter's CA certificate file cannot be generated. Then right-click on the workbench to add -> non-test components -> HTTP proxy server. Select the default port is 8080. Just click Start.

After clicking Start, a pop-up page prompts that the CA certificate has been generated and is in the Bin directory. Click OK.

(3) Open Jmeter agent

Find the toolbar "Options" -> SSL Manager. Open ApacheJMeterTemporaryRootCA.crt in the bin directory.

(4) Modify the HTTP request

Now that the proxy has been set up, re-modify the created HTTP request. Add the proxy server at the bottom Proxy server: localhost (Jmeter proxy built on this machine), the port number is 8080. Just save the whole plan.

(5) Add HTTP request header

Since my request body data is of type json, the content-Type of the default HTTP request header is application/x-www-form-urlencoded. So we need to add an HTTP request header based on the HTTP request, and set the Content-Type to application/json type.

(6) Add result view tree

Add->listener->view result tree after HTTP proxy.

(7) Execute HTTPS requests and view the results

Click Save on the toolbar, and then click the Run button, and then you can view the running results in the result tree. We see that the operation is successful, indicating that the HTTPS request is successful!

Fiddler capture of HTTPS -- jmeter request