Chisel: A fast TCP/UDP tunnel over HTTP | Hacker News Reader

Chisel: A fast TCP/UDP tunnel over HTTP

github.com

289 pointslyu0728259 comments

I've used this before and it's great as a "reverse tunnel" when you have a VM in the cloud that does allow configurable port forwarding/firewall rules but need to connect "peer to peer" to a customer in a workshop who has the typical "my router blocks everything and we aren't going to spend the time supporting every workshop's possible inbound network connection setup".

It helps for "flipping" the "server connects to client".

But... it gets detected as malware really easily haha

> But... it gets detected as malware really easily haha

It's a common tool in the red teamer's toolbox.

Just search "chisel" on https://ippsec.rocks to see how often it's utilised in a pentest type of scenario.

It is used by red teamers because it is used by attackers.

https://malpedia.caad.fkie.fraunhofer.de/details/win.chisel

Well it's used by both because it's pretty useful in attack-like situations.

Tomato tomahto

Tomatoe, tomato. The E at the end of the word generally reflects hardening/lengthening the preceding morpheme (rid, ride; cloth, clothe).

This is a good example of how language evolves because tomahto has not ever been a correct spelling of tomato, and tomatoe is an incorrect spelling derived from making tomato plural into tomatoes and then (incorrectly) dropping just the s to make tomatoes singular again. A mistake based off of a mistake. So while intelligible if incorrect, who's to say if it's wrong?

by that you mean, the traffic is suspicious or the binary?

Both the protocol tunneling activity and the binary would likely be flagged by most enterprise security software.

Having used this as a part of a solution we were delivering to corporate customers, the traffic wasn't causing problems (we were tunneling over secure WebSockets, though, not plain text ones). It's only those overzealous "malware detection" tools that caused us to have to drop it and come up with a different way of encrypting our traffic.

The protocol is http(s) so it looks quite generic, are you transiting the GFW? Probably shouldn't be.

That makes it kinda useless.

What we need is a self-updating mechanism. See for instance yt-dlp, which breaks every now and then but a simple update almost always puts you back in action. We need something similar for tunnels.

What benefit would a self-updating mechanism provide?

Assuming they mean a cat and mouse game like ytdl where the software is updated once it starts getting detected by the enemy.

How will it self update after it's been deleted by the AV? Also, there are many AVs with different detection strategies. It's not always static analysis that can easily be defeated by slightly changing some lines of code.

I was thinking more about it being filtered by firewalls.

I don't think Chisel has a goal of evading AV detection.

I was tempted to play the cat and mouse AV detection game though decided against it. It’s open source and with effort, one can make it avoid detection, but I’ll leave that up the reader

I am curious to see benchmark results for the same use cases but with 10ms and 100ms latency added between the client and server. It looks like the bench currently just stays within the same machine.

I do not often operate below application layer, but as I understand it both the HTTP and SSH layers would add back-and-forths from client to server that UDP does not perform. Would UDP over HTTP over SSH have a slowdown steeply (but linearly?) correlated with the ping to the server? And (>linear) increased effects on packet loss? Crowbar seems to only do HTTP, so saves some considerable amount of backs-and-forths... but doesn't have the benefit from websockets...

You’re right, that’d be a better test - and I think the gap between chisel and crowbar would grow even more. Chisel is effectively doing ssh tunnelling, with extra layers. Performance is lost in packet wrapping/unwrapping, reduced MTU but it shouldn’t result in more round trips

Hey all, I’m the author of chisel. Feel free to send any questions my way

Not really a question, but just wanted to say I appreciate your work it is a great piece of software thank you for open sourcing it!

I have been using the TCP proxy project you have on github. Thank you for open sourcing.

Can I get in touch with you in any way? We have some interesting problems, would love to hear your thoughts.

What a lovely euphemism for "can we get some free support for our edge case".

Please don't jump to conclusions. I would really encourage you to not respond If you do not understand how long term relationship and trust are built in tech or any other business.

Please don't be a troll.

Having been on the receiving end of similarly phrased requests, I can assure you that was nowhere close to trolling.

The fact that the OP is not easy to reach is not an oversight on their end. Take a hint and go through channels that they left open, i.e. issues on GH.

If your request has merit, you will hear back.

Thank you. Your suggestion is helpful. Will do that.

Chisel – A fast TCP tunnel over HTTP - https://news.ycombinator.com/item?id=13353457 - Jan 2017 (38 comments)

Chisel is a handy red-team tool. I learned about it training for the OSCP (Offsec Certified Professional). It comes in handy under certain situations.

Another tool I recommend is Ligolo-ng [1]. You set up a network interface and use "ip route" to send traffic through it. In a way, it "feels like a VPN".

[1] https://github.com/nicocha30/ligolo-ng

Seems to be the exact opposite of https://github.com/fatedier/frp which is a reverse tunnel over a variety of protocols (including HTTP).

I've used both chisel and frp to tunnel connections, then ended up using good old autossh. Just nothing beats it when you need a ubiquitous tool to provide a near permanent tunnel that will keep the connection up and use standard encryption.

In my experience SSH traffic is blocked quite regularly by corporate firewalls.

Do you mean the protocol, or just port 22?

Both. Some less sophisticated network gear might allow you to connect to an SSH server on port 80 for example. But usually you’ll have a traffic inspecting firewall that isn’t fooled that easily.

How does this compare to something like MASQUE (i.e. TCP, UDP, or even IP proxied over HTTP/3, /2 or /1)? Does this just predate it and it's basically the same principle?

This has got to be at least the third FOSS project I've seen called Chisel or some homophone thereof.

It's a great post-exploit tool as well hacking but these days it gets blocked/detected a lot. Where ssh traffic isn't blocked, the builtin win10+ openssh client's dynamic reverse proxy works ok too.

Why not just use an HTTP CONNECT proxy?

That doesn't give you full IP tunneling, only a TCP socket connection, which might or might not be enough for what you're trying to do.

I could also imagine that many corporate firewalls know HTTP CONNECT and filter it.

With CONNECT-UDP you also get UDP, just like this, and over HTTPS it's not going to be filterable, right?

Yeah, I suspect it's pretty similar using HTTP/2 when considering all of these new proxy modes; I've been wondering as well if there are any other differences or if it just predates the specification of that (and UDP over HTTP).

With HTTP/1, I don't think there is a way to multiplex multiple TCP or UDP bindings over a single connection – maybe this supports it? The diagram seems to suggest it, and e.g. SSH does too (and is equivalent to CONNECT proxying over HTTP/2 in that sense).

Large enterprise firewalls generally do not allow true end-to-end HTTPS. The firewall masquerades as the destination sites using custom certificates, issued on-the-fly under a custom root CA controlled by the firewall, which is pre-installed on every device approved for use in the enterprise. Certain sites (e.g. banks) and certain users (e.g. C-suite) may be exempt from this by policy, but the default policy is to MITM all connections.

Using Proxytunnel [1] to do specifically this, in an environment where a packet inspecting proxy prevents SSH traffic.

It supports connecting over HTTPs, so the traffic doesn't look fishy with the setup of: SSH Client -> HTTPs Encryption -> Corporate Packet Sniffing Proxy -> Your Server -> HTTPs Decryption -> SSHD Server

Looking forward to explore chisel as well.

[1] https://github.com/proxytunnel/proxytunnel

How does this compare to Tailscale/Headscale?

Tailscale is Wireguard this is HTTP. Different protocol?

Tailscale does actually support Wireguard packet forwarding over HTTP (a custom addition to the protocol; standard Wireguard only runs on UDP) for tricky NAT traversal use cases, but that's only used in pretty gnarly situations. Otherwise, it's a regular VPN, i.e. encapsulated and encrypted IP over UDP.

https://tailscale.com/blog/how-tailscale-works#encrypted-tcp...

Very interesting! Always wondered what the value add was and this is one of them

Yes, reliable NAT and firewall traversal is basically the make-or-break feature for "P2P"/mesh VPNs.

And Tailscale is doing a great job at trying to only resort to relaying when there's really no other choice, both because it improves latency and saves them bandwidth on their relays.

It's very similar to VoIP and videocalls (1:1; conferencing usually performs better with SFUs) in that regard.

Tailscale is a virtual network device (works on L3, tun not tap device) whereas chisel just listens on ports (works on L4)

is it possible to turn this into an executable that can run cross-platform ?

That’s exactly what it is, see releases

I feel afraid to ask, but considering HTTP is transmitted over TCP, why would you tunnel TCP back again?

Actually, nvm I don't need to know, you can keep your cursed ourobouros protocol to yourself.

Yes, it can cause a problem called TCP Meltdown where the inner TCP and the outer TCP both try resending data and the connection degrades significantly. I think you can work around it, somewhat, by tweaking the TCP timing. But generally it's best to use UDP for the outer protocol when you're tunneling TCP

I don't think that's the case here. I think it's just tunneling the data, not the full TCP packets.

I was not aware, thanks.

Correct, it’s equivalent to ssh tunneling except there’s some HTTP/websocket wrappers around it

I don't think it's tunneling the full TCP packets. I think it's extracting the data stream from the incoming TCP stream, tunneling that data, and creating a new TCP stream to the destination on the other end of the tunnel.

So basically the same as ssh -L or ssh -R .

It's for getting arbitrary traffic out of corporate firewalls by disguising it as regular HTTP traffic.

Afraid to ask but not afraid to insult?

Reply on news.ycombinator.com