In today’s article, we are going to take a look at the challenges in scripting web applications that use a secure HTTP connection a.k.a. HTTPS connection to communicate with the server.
I’m sure we’ve all been there at some point of time or the other, where we try to record a web page that uses HTTPS, only to end up with nothing recorded. Why would this happen? Why does HTTP recording work and HTTPS does not? How can we workaround this? This article aims at answering these questions.
First, let us try to understand some of the basics of HTTP(S) communication.
What is the difference between plain HTTP communication and HTTPS communication?!
When a client communicates with a server using plain HTTP protocol, all the communication happens in a format that could be understood by anyone intercepting the communication, with little effort. In HTTPS communication though, all the traffic between the client and the server is encrypted. So, even if someone is able to eavesdrop on the communication, they cannot make any sense of the data being transmitted.
What is the challenge in recording applications using HTTPS protocol?!
The most common method used by the performance testing tools to record user interaction with an application is by acting as a proxy between the client browser and the server. This way, all the traffic between the client browser and the server must go through the proxy which can record this communication for later use (typically to replay this recording to simulate real user interaction)
If this communication is in plain HTTP, then the tools have no problem understanding the communication. Recording the client-server communication is straight forward. In the case of HTTPS communication though, the communication is encrypted. So, the recording tool cannot decipher the communication and hence cannot record the client-server communication for later replay.
What is the solution?
Most performance testing tools work around this issue by the use of temporary root certificates.
For each request using the HTTPS protocol, the recording/performance test tool retrieves the certificate provided by the SSL server. This certificate is essential to ensure secure communication between the tool and server. Moreover, the test tool takes on the role of the server, issuing a certificate that is sent to the browser to secure communication between proxy and client. Essentially, the tool tries to act as the server to the browser/client and acts as the client to the (web)server.
This certificate, created by the test tool during recording, is not recognized by the browser as being valid, since it is not authenticated by any certificate authority. The browser displays messages warning that the certificate provided by the server (in this case, the recording tool) cannot be trusted and consequently, the connection cannot be secured.
To work around this, the temporary root certificate provided by the test tool needs to be imported into the certificate authorities keystore of the browser. This enables the certificate generated during recording to be authenticated, thus preventing the display of certificate error messages in the browser.
Now, it becomes possible to record HTTPS communication between the client and the server.
Example: How to install a root certificate?
Each test tool vendor will provide their own root certificates to enable HTTPS recording. The procedure to install these certificates is more or less similar. For the purposes of this article, let us pick up JMeter as an example and see how we can get JMeter’s temporary root certificate installed.
Double click on the highlighted root certificate, typically available in JMETER_HOME/bin folder
Follow the dialog’s shown below to finish installation
Hope this helped!