In modern days, most of applications used in an organization are web based and in Client/Server architecture. A Client creates a request and sends it to the server . In return, the server processes the request and return an answer back. End users(clients) mostly use their browsers as client application to interact with the server. Sometimes, we hear complaints from our clients(end users) about how slow the network or the server is. Network and system administrators first check the routine procedures.
For example checking client reachability by ping is one of the first thing to do. If we get a reply from the client, we measure latency with ping round trip time, if everything is ok with reaching the client, we move to the next step which could be checking firewall rules for upper layer protocols for ssl/tls or other protocols. After following routine steps, if we can not fix the problem, we may need to analyse the requests packet by packet.
Since security is a big concern for organizations, they add a security layer to their applications. Analysing the requests packet by packet may not give us the desired result we want when packets are encrypted with SSL/TLS.
SSL (Secure Socket Layer) and TLS (Transport Layer Security) are both cryptographic protocols that provide authentication and data encryption between clients and servers. TLS is the successor protocol to SSL. In other saying, TLS is just an updated, more secure version of SSL. These days, since SSL is outdated, organizations extensively use TLS.
When a client connects to a server, it completes TCP 3 way handshaking. After that, TLS handshaking starts in which client and server negotiate what version of SSL/TLS will be used, which cipher suite will encrypt communication and so on. During TLS handshaking both the client and the server derive session keys. The whole process is summarized in the figure below.
Back in the old days, organizations used public/private(RSA) keys to exchange session keys. In this method, a sever simply sends it’s corticate and public key to it’s client and the client creates session keys and encrypt the keys with the server public key and sends encrypted keys back to the server. In the end of the process, the client and the server end up deriving the same keys and secure communication starts. There is a serious security issues with this method. If an attacker obtains server private key, he/she can decrypt all the traffic. The worse is that he/she can decrypt not only current traffic but also the traffic that will be created in the future as well.
This is a big concern to organizations. As time passed, IT industry needed a better way that supports PFS(Perfect Forward Secrecy). PFS is an encryption system that changes encryption and decryption keys frequently. It uses different keys for each connection even during the connection encryption and decryption keys can be changed. The keys generally stored in memory. After connection is tear down, the keys are deleted automatically. Diffie Hellman key exchange is an alternative way to public/private(RSA) key exchange. Unlike public/private(RSA), Diffie Hellman key exchange supports pfs.
Wireshark supports decryption of traffic, using session keys created by both Diffie Hellman and public/private(RSA) key exchange. In this article, my main focus will be to decrypt SSL/TLS protocols without diving too deep into details, which can be a topic for another article. We need SSL/TLS session keys for decryption but how do we obtain them?
NSS is a collection of cryptographic libraries, which is design to support cross-platform development of security enabled client and server systems. Application that uses NSS can support SSL, TLS and some other security standards. Both Firefox and Chrome support NSS. When it comes to Internet Explorer, We can say Microsoft uses it’s own libraries which can be a topic of another article for us. Thanks to NSS, now we can capture session keys for feeding Wireshark.
We will use firefox as the client and connect to a web server while we capture pcaps and keys that will feed wireshark. As a first step, we will make NSS log the session keys into a text file. Keys logging can be enabled by setting the environment variable SSLKEYLOGFILE to point to a file.
Let’s create SSLKEYLOGFILE environment variable that contains the path where keys are stored in Windows 10. The instructions are below.
Right click on “Computer” and select “Properties” from the menu.
“System” window will open then click on “Advanced system settings”.
“System Properties” window will pop up and click on the bottom right button saying “Environment Variables…”.
Another window will open, click “New” button which lets you add a new environment variable
After opening “New User Variable” window, we need to define our own environment variable. Type SSLKEYLOGFILE in the box named “Variable name:” then type your path or use “Browse File..” button to pick a file for “Variable value:”. I typed a path to a folder on my desktop.
Once finishing up, We click “OK” button and now NSS will collect client and server handshake traffic secret keys in the file.
Before running Wireshark to collect packets, we need to verify that we log session keys. We open Firefox and type into address bar any domain that uses https. I will type www.golinuxcloud.com. Now it is time to check the log file. Below you see my session keys are collected.
From this point, we will work with wireshark, steps as below.
We do not want to capture all packets coming ang going through our interface so we create a capture filter like below. I am going to use www.golinuxcloud.com domain name as seen in the figure below. You can use an IP address instead of a domain name as well. Then pick the interface from which you want to capture the traffic.
Next, click Edit menu, then Preferences and Wireshark-Preferences window will pop up. On the left pane, you will see “Protocols”, click on it to expand the tree. Scroll down, then click on TLS.
From “(Pre)-Master-Secret log filename” , use Browse button or paste path of the log file and click OK to finish.
The last step is to visit a secure web site that uses https.
Wireshark now have both session keys and packets to decrypt SSL/TLS. You can see undecrypted pcaps below before decryption. The first 3 packets are the 3 way handshake setting up the connection between the client and the server. The next 4 packets belong to TLS handshaking. Following, the actual application data (http get request) is sent in encrypted form.
The decrypted traffic is below. The first 7 packets are the same, but following packets are in green color and we can read the requests in clear text from “info” column.
To see more details, we can click on the row(packet) that contains http GET request. As seen below, Our request uses http version 2, GET method, showing the details of the domain we connected and much more about the request.
SSL and TLS are both cryptographic protocols that provide authentication and data encryption between clients and servers. Sometimes we need requests to be in clear text format. Wireshark is a great tool to decrypt SSL/TLS to data in clear text form.
He is proficient in System Administration, Python, Computer Network, Network Engineering, PHP, Web Testing, Penetration Testing, Wireshark, RADIUS, Cisco Router, TCP/IP, Kali Linux, OSPF, NPS, and Multiprotocol BGP. You can connect with him on his LinkedIn Profile.
Can't find what you're searching for? Let us assist you.
Enter your query below, and we'll provide instant results tailored to your needs.
If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.
For any other feedbacks or questions you can send mail to admin@golinuxcloud.com
Thank You for your support!!