Seriously though, Chisel is a client + server bundle in a single application written in Go that allows you to create secure tunnels bypassing firewall restrictions.
So we already know that chisel uses TCP, HTTP and SSH, but let's figure out what it does for what.
Basic concepts
Chisel server is a process running on a computer with an external (accessible) IP address. The server listens for incoming connections from clients via HTTP/HTTPS and manages traffic redirection.Chisel Client - The client runs on a remote host that wants to tunnel traffic through the Chisel server. It connects to the Chisel server via HTTP or HTTPS and passes requests to the required ports.
HTTP Tunneling - Chisel uses HTTP(S) to transmit data, which allows it to bypass network-level restrictions such as specific port blocking. All TCP traffic between the client and server goes through the HTTP channel, creating a tunnel that looks like regular HTTP traffic.
WebSocket is a protocol that allows a persistent connection between a client and a server over TCP/IP. Unlike traditional HTTP requests, which are one-time, WebSocket provides real-time, two-way communication. Chisel uses WebSocket to create a persistent tunnel through which it sends data between the client and the server.
Example of WebSocket connection
Tunneling data via WebSocket
Once a WebSocket connection is established, the client can send data through the tunnel. All data transfer is encrypted and encapsulated in WebSocket frames, allowing traffic to be sent using the standard port 443 (or 80), which is often not blocked by firewalls.Chisel allows you to transmit not only HTTP traffic, but also data from other protocols, such as TCP and UDP. This means that you can tunnel, for example, SSH sessions or any other TCP/UDP traffic.
Chisel does not create a full-fledged VPN that operates at the IP level (like OpenVPN or WireGuard, for example). Instead, it operates at the TCP/UDP level, encapsulating data packets in WebSocket frames and forwarding them to the server, which in turn forwards them to the destination address (for example, an SSH server).
Encapsulation stages
1. Transfer of initial data:The client application generates network data. This can be TCP/UDP packets, for example, when establishing an SSH session or other network interaction.
2. Encapsulation in WebSocket frames:
The Chisel client takes this data and wraps it into WebSocket frames. Each frame will contain a small portion of the original data, which is broken down into segments.
3. Transferring data via WebSocket :
These frames are transmitted over an established WebSocket connection between the client and the Chisel server. The connection is usually established over HTTP(S), which makes the traffic look like regular web requests and makes it difficult to block.
4. Decoding on Chisel server :
The Chisel server receives WebSocket frames, extracts encapsulated data from them and decodes them, reconstructing the original TCP/UDP packets.
5. Transferring source data to the target server :
After decoding, the Chisel server transmits the recovered data to the desired address - this can be a remote SSH server or any other application with which the client wanted to establish a connection.
6. Return traffic :
When the target server responds, the process is repeated in reverse: the data is encapsulated by the Chisel server, transmitted through a WebSocket tunnel back to the client, where the data is decoded and passed to the original application.
Why is CHISEL difficult to detect?
Using standard ports
Many firewalls are configured to allow traffic only to certain ports, such as:- Port 80 is for HTTP.
- Port 443 — for HTTPS.
These ports are used for web traffic and are not usually blocked to prevent users from accessing websites on the internet. Chisel uses WebSocket over HTTP(S), which allows it to work through these ports.
Why is this important:
- Since Chisel operates over standard web ports (80 or 443), firewalls often let such traffic through without checking its content. Even if non-HTTP data is being transmitted on the server or client side, firewalls only see "normal" connections over allowed ports.
WebSocket over HTTPS
Chisel uses WebSocket over HTTPS (on port 443). This makes Chisel traffic virtually indistinguishable from regular HTTPS traffic. Many firewalls and Deep Packet Inspection (DPI) systems can inspect the contents of HTTP sessions, but HTTPS traffic often cannot be analyzed in detail due to encryption.Why it works:
HTTPS encryption (via TLS/SSL) protects data from interception and analysis. Since firewalls cannot decrypt the contents of an HTTPS session, they do not see that there is tunneled Chisel traffic inside. The connection looks like a regular HTTPS session, which is encrypted, and the firewall cannot distinguish it from web surfing.
Traffic masking
Chisel essentially disguises any data sent through it (be it SSH, HTTP, or any other TCP/UDP traffic) as regular web traffic. Since the firewall expects to see standard HTTP/HTTPS requests on ports 80 and 443, it doesn't always check what exactly is being sent within these sessions.Working in NAT and proxy servers
Chisel can work even when the client is behind a NAT (Network Address Translation) or through a proxy server. Since WebSocket works on top of HTTP/HTTPS, and HTTP requests and responses themselves can freely pass through NAT or proxy, Chisel traffic can easily bypass such network restrictions.Let's try it in practice
In order to see how exactly this utility works, we will make a small laboratory, which will consist of a Linux Server (Ubuntu) and a Linux Client (Kali Linux)Chisel Server Setup
Download and compile the latest version of the utilityBash:
r
Bash:
sudo apt install golang-go
git clone http://github.com/jpillora/chisel && cd chisel
go build
Bash:
./chisel server -v -reverse -p 8000
Chisel Client Setup
We do the assembly in the same way
Bash:
sudo apt install golang-go
git clone http://github.com/jpillora/chisel && cd chisel
go buildLet's connect to our server
Bash:
./chisel client <server ip address>:8000R:127.0.0.1:8890:<client ip address>:80 &
Traffic analysis
As a result, we see communication between two hosts encrypted using L7 frames.
