[HN Gopher] Chisel: A fast TCP/UDP tunnel over HTTP
___________________________________________________________________
Chisel: A fast TCP/UDP tunnel over HTTP
Author : lyu07282
Score : 266 points
Date : 2024-04-04 10:47 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| MuffinFlavored wrote:
| 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
| asib wrote:
| > 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.
| mike_d wrote:
| It is used by red teamers because it is used by attackers.
|
| https://malpedia.caad.fkie.fraunhofer.de/details/win.chisel
| maxcoder4 wrote:
| Well it's used by both because it's pretty useful in
| attack-like situations.
| arcanemachiner wrote:
| Tomato tomahto
| halJordan wrote:
| 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?
| passion__desire wrote:
| by that you mean, the traffic is suspicious or the binary?
| magnoliakobus wrote:
| Both the protocol tunneling activity and the binary would
| likely be flagged by most enterprise security software.
| tsimionescu wrote:
| 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.
| halJordan wrote:
| The protocol is http(s) so it looks quite generic, are you
| transiting the GFW? Probably shouldn't be.
| amelius wrote:
| 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.
| Thorrez wrote:
| What benefit would a self-updating mechanism provide?
| globular-toast wrote:
| Assuming they mean a cat and mouse game like ytdl where the
| software is updated once it starts getting detected by the
| enemy.
| mr_mitm wrote:
| 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.
| globular-toast wrote:
| I was thinking more about it being filtered by firewalls.
| Thorrez wrote:
| I don't think Chisel has a goal of evading AV detection.
| jpillora wrote:
| 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
| dang wrote:
| Related:
|
| _Chisel - A fast TCP tunnel over HTTP_ -
| https://news.ycombinator.com/item?id=13353457 - Jan 2017 (38
| comments)
| mattmerr wrote:
| 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...
| jpillora wrote:
| 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
| lxgr wrote:
| 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?
| niux wrote:
| How does this compare to Tailscale/Headscale?
| killingtime74 wrote:
| Tailscale is Wireguard this is HTTP. Different protocol?
| lxgr wrote:
| 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...
| killingtime74 wrote:
| Very interesting! Always wondered what the value add was
| and this is one of them
| lxgr wrote:
| 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.
| jpillora wrote:
| Tailscale is a virtual network device (works on L3, tun not tap
| device) whereas chisel just listens on ports (works on L4)
| nurettin wrote:
| 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.
| nier wrote:
| In my experience SSH traffic is blocked quite regularly by
| corporate firewalls.
| nurettin wrote:
| Do you mean the protocol, or just port 22?
| veganjay wrote:
| 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
| spxneo wrote:
| is it possible to turn this into an executable that can run
| cross-platform ?
| jpillora wrote:
| That's exactly what it is, see releases
| TZubiri wrote:
| 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.
| mordechai9000 wrote:
| 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
| Thorrez wrote:
| I don't think that's the case here. I think it's just
| tunneling the data, not the full TCP packets.
| mordechai9000 wrote:
| I was not aware, thanks.
| jpillora wrote:
| Correct, it's equivalent to ssh tunneling except there's
| some HTTP/websocket wrappers around it
| Thorrez wrote:
| 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 .
| globular-toast wrote:
| It's for getting arbitrary traffic out of corporate firewalls
| by disguising it as regular HTTP traffic.
| remram wrote:
| Afraid to ask but not afraid to insult?
| jpillora wrote:
| Hey all, I'm the author of chisel. Feel free to send any
| questions my way
| lyu07282 wrote:
| 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!
| debarshri wrote:
| 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.
| huhtenberg wrote:
| What a lovely euphemism for "can we get some free support for
| our edge case".
| debarshri wrote:
| 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.
| huhtenberg wrote:
| 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.
| debarshri wrote:
| Thank you. Your suggestion is helpful. Will do that.
| shawnz wrote:
| Why not just use an HTTP CONNECT proxy?
| lxgr wrote:
| 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.
| shawnz wrote:
| With CONNECT-UDP you also get UDP, just like this, and over
| HTTPS it's not going to be filterable, right?
| lxgr wrote:
| 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).
| kbolino wrote:
| 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.
| FrostKiwi wrote:
| 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
| snitty wrote:
| This has got to be at least the third FOSS project I've seen
| called Chisel or some homophone thereof.
| remram wrote:
| Seems to be the exact opposite of https://github.com/fatedier/frp
| which is a reverse tunnel over a variety of protocols (including
| HTTP).
| badrabbit wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-07 23:02 UTC)