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
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?
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
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.
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.
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.
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
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.
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.
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".
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.
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?
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.
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
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.
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).
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.
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.
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.
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
It helps for "flipping" the "server connects to client".
But... it gets detected as malware really easily haha