Understanding HTTPS Man-in-the-Middle Attacks: Tools and Techniques for Analyzing Website Traffic

Is HTTPS Really Secure? Let’s Discuss the Man-in-the-Middle Attack You Might Not Know About

A covert proxy tool utilizing HTTPS man-in-the-middle attacks to eavesdrop on website traffic.

0x1 Why This Tool?

The network analysis tools I commonly use include: Fiddler, Charles, whistle, WireShark and Tcpdump

Fiddler, Charles, and whistle focus on network protocols within the OSI application layer. Wireshark and Tcpdump capture all network traffic data, often used for locating binary protocol network failures, thus not included in this comparison. Fiddler and Charles are respectively suitable for Windows & macOS, each with its own advantages. Whistle’s feature is cross-platform, running on both Windows and macOS, and it is open-source under the MIT license. While retaining the benefits of Fiddler and Charles, it adds many features. If you’re interested, you can continue reading.

0x2 Introduction

Whistle is a cross-platform web debugging proxy tool based on Node. Like all web debugging proxy tools, whistle is primarily used to view and modify HTTP, HTTPS, and WebSocket requests and responses, or as an HTTP proxy server. Unlike Fiddler+Willow and Charles which modify requests and responses through breakpoints, whistle uses a method similar to configuring Hosts to modify request and response data, providing grouped rules and three matching methods: domain, path, and regex. Specifically, for end debugging, it offers features such as weinre and log, and supports extension through Node modules.

0x3 Packet Capturing Principle: Man-in-the-middle

Man-in-the-middle (MITM) can create connections with both ends of network communication, exchanging the received data, making both ends think they are directly communicating with each other, controlled entirely by the man-in-the-middle. Simply put, to the real server, the man-in-the-middle is the client; and to the real client, the man-in-the-middle is the server.

There are various ways to implement man-in-the-middle attacks, which won’t be discussed here. Some common HTTP/HTTPS packet capturing and debugging tools achieve traffic interception by creating a local Proxy service and modifying the browser’s Proxy settings. Their working principles are consistent with man-in-the-middle attacks. The tools I’ve used include: Fiddler, Charles, and whistle.

This article mainly discusses the HTTPS man-in-the-middle. A simple diagram is as follows:

“`code language: txtcopy

Server <---> Local Proxy <---> Browser         ^                 ^       HTTPS(1)          HTTPS(2)

“`

The above HTTPS(1) connection is made by the man-in-the-middle impersonating the client to establish a connection with the server. Since HTTPS servers generally do not authenticate client identity, this step is usually without issue. However, for the HTTPS(2) connection, the man-in-the-middle must possess the corresponding domain certificate private key to impersonate the server. To acquire the private key, an attacker can only: 1) retrieve it from the website server; 2) issue a certificate from the CA; 3) issue a certificate themselves.

To guard against the first two points, the website needs thorough security measures, from host security to website security (to prevent private key theft), from DNS resolution security to domain email security (to prevent re-certification by attackers). An attacker’s self-issued certificate cannot pass the system’s built-in root certificate validation, rendering it unusable for man-in-the-middle attacks by default.

For tools like whistle, the key to decrypting HTTPS traffic lies in importing their own certificates into the system’s trusted root certificate list, enabling their self-signed certificates to be trusted by browsers. By entering the “HTTPS” tab in whistle settings and selecting the relevant functions, HTTPS traffic can be decrypted and modified smoothly. You can see such a certificate chain in the browser:

>>

0x4 Quick Start

1. Install node

“`txtcopy

npm install -g node

“`

1. Install whistle

“`txtcopy

npm install -g whistle

“`

1. Start whistle

“`txtcopy

w2 startWhistle default port is 8899, to change the port number, start it like:w2 start -p 8888Restart whistle:w2 restartStop whistle:w2 stopFor more content, check command line help:w2 help

“`

1. Configure the proxy

“`txtcopy

Whistle requires manual configuration of the browser’s proxy or system proxy (proxy IP is the IP of the machine where whistle is installed, if local it is 127.0.0.1; the port number is the port set at startup, default is 8899), here we use the Chrome proxy extension (SwitchyOmega)

“`

1. Trust the certificate to enable HTTPS traffic decryption

“`txtcopy

Based on the principle mentioned above, we need to download and trust the root certificate to perform proxy network requests for man-in-the-middle attacks, thus achieving data decryption capture

“`

0x5 Getting Started

Enter 127.0.0.1:8899 #network in your browser to see the following interface

Mainly divided into three parts:

• Menu bar, generally for importing/exporting network data, usually in text or saz format, the latter is compatible with Fiddler’s import/export
• Main content, showing the HTTP(s) requests we sent. Each item contains
  • Result: RFC2616 StatusCode
  • Method: RFC2616 Method
  • Protocol: Http(s) | ws(s)
• Click any entry in the main content to display the request and response of the corresponding entry on the right

0x6 Scenario One: Capturing Mobile Network Packets

If we need to capture packets from a mobile app, the phone also needs to trust the certificate generated by the man-in-the-middle. Open the address http://192.168.0.4:8899 in Safari, find the HTTPS option, download and trust the root certificate. Please ensure your computer and phone are on the same local area network. Once set up, all web traffic from the phone will be taken over by whistle installed on your computer. All Http(s) traffic becomes visible under this tool. Let your imagination run wild and explore creative possibilities. Good luck!

0x7 Scenario Two: Debugging WebSocket Traffic

In addition to basic HTTP protocol traffic detection, it also supports the WebSocket protocol. Open a WebSocket testing site in your browser, and send some text messages.

Then go back to the initial traffic monitoring tab and check the Frames on the right side. You will see all the messages you just sent displayed here.

0x8 Scenario Three: Replaying Data

Select an item on the left, drag it to the right, and the details of the selected data packet will appear in the red box on the right. We can modify the request body in the Composer menu item to replay the request, useful during software development for debugging network interfaces, especially in long operation paths. With this tool, we can conveniently start testing from the middle steps, rather than restarting from scratch after a failure. In certain cases, it can also assist system testing experts in evaluating website security by modifying parameters to verify the site’s security.

0x9 Scenario Four: Online Page Injection Debugging

0xa More Resources

• https://github.com/avwo/whistle#documentation
• https://imququ.com/post/how-to-decrypt-https.html
• https://tools.ietf.org/html/rfc2616#page-36
• https://tools.ietf.org/html/rfc6455