Live data from Hacker News

Chisel – A fast TCP tunnel over HTTP

github.com

21–30 of 41 posts

Re: Chisel – A fast TCP tunnel over HTTP

#21

Many superlatives, which immediately raise suspicions. If you are trying to solve the problem of NAT traversal and such, I suggest you rather attempt to do this: https://en.wikipedia.org/wiki/TCP_hole_punching

this surely is great and i can't wait for a moment when someone finally comes up with a TCP Hole Punching as a Service. vpnazure kinda does this, but has the overhead of softether vpn service on top of it... I would rather go with punching myself an ssh port.

I do it at Wormhole[1] in a very similar fashion to "vpnazure"; also with SoftEther.

Why would you rather "punch yourself and ssh port"? Do you mean that your main problem with vpnazure and the like is the need of an agent/client software installed? I am not sure I understood your concern, but I would be very interested in hearing more about it. Feel free to email me to the address on my profile if you prefer, although a reply here works for me.

IMHO the best way to make it transparent for any application is to have a virtual interface. It offers an expected environment for any new or legacy app (instead of proxying stuff explicitly).

Thanks!

[1] https://wormhole.network

Re: Chisel – A fast TCP tunnel over HTTP

#22
post #17

Earlier quoted context omitted.

Hmm, this choice is indeed strange, websockets still are blocked in some restrictive set ups (squid?). But still, what is the way of doing stream in both directions? Do you mean opening multi-part form data for uploading and transfer encoding chunked for download? But that would be 2 tcp connection for 1 tcp tunnel. And I believe there's no other way to do it without the overhead of HTTP request/response headers.

Not necessarily ... you would have to issue a HTTP request per uplink chunk but HTTP can use connection pooling so that does not necessarily translate to a single TCP connection [0] Agreed it's not quite as straightforward as the parent poster suggests. I can see issues with this approach for realtime/streaming applications but for applications relying on a similar request/response flow of traffic it would do the job…

Yes, and for various reasons those chunks can be reordered. And a misbehaving proxy might also try to cache them. And to send data back from the server you need long hanging gets, which can also be subject to timeouts and weird chunking by misbehaving proxies.

These problems are all solvable, but you need to treat http requests like datagrams and (basically) reimplement TCP on top of HTTP.

We've done this several times now. I made one[1] myself a few years ago based on google's browserchannel implementation (that was first written for gchat inside gmail. It supported browsers down to IE5.5). But the best is probably SockJS - https://github.com/sockjs . IIRC Its written by some (ex?) vmware guys, and its great.

But all this stuff is pretty outdated now. Misbehaving corporate proxies are (thankfully) getting much rarer - especially if you tunnel your traffic over HTTPS.

These days you should just use websockets directly.

[1] https://github.com/josephg/node-browserchannel

Re: Chisel – A fast TCP tunnel over HTTP

#23

Earlier quoted context omitted.

They can't block websockets over https.

Most corp+school firewalls block https or make the user add a MITM cert (well, it's managed via active directory for company machines). Rarely do these firewalls allow websockets.

How common is this, actually? My impression is its fairly rare, but I'd love to see some actual analytics if anyone has some.

Re: Chisel – A fast TCP tunnel over HTTP

#25

Earlier quoted context omitted.

They can't block websockets over https.

Most corp+school firewalls block https or make the user add a MITM cert (well, it's managed via active directory for company machines). Rarely do these firewalls allow websockets.

K-12 schools definitely block HTTPS at some places, mostly because they can't inspect it.

Re: Chisel – A fast TCP tunnel over HTTP

#26
post #25

Earlier quoted context omitted.

Most corp+school firewalls block https or make the user add a MITM cert (well, it's managed via active directory for company machines). Rarely do these firewalls allow websockets.

K-12 schools definitely block HTTPS at some places, mostly because they can't inspect it.

Wow, so they can only use HTTP? That seems crazy. Would be fun to try and mess with the network though. Yeesh.

Re: Chisel – A fast TCP tunnel over HTTP

#28

Hold on, hold on, hold on. Let me get this straight: you took an application layer protocol (HTTP) that runs on top of TCP and ...reimplemented TCP over it!? (see: https://www.quora.com/What-is-the-difference-between-HTTP-pr... )

Pfft. Amateurs!

> Once upon a time at evening I have decided to properly brake the famous browsers communication problem and as a result you have landed in here. I have created implementation of BNC networks model with simple TCP/IP layer, that as transport packet it will use browser's cookie object.

http://theprivateland.com/bncconnector/index.htm

Re: Chisel – A fast TCP tunnel over HTTP

#29
post #25

Earlier quoted context omitted.

K-12 schools definitely block HTTPS at some places, mostly because they can't inspect it.

Wow, so they can only use HTTP? That seems crazy. Would be fun to try and mess with the network though. Yeesh.

Not common anymore. Now it's usually an ssl proxy that uses a cert on all computers to mitm the connection and enforce policies.

Re: Chisel – A fast TCP tunnel over HTTP

#30

Many superlatives, which immediately raise suspicions. If you are trying to solve the problem of NAT traversal and such, I suggest you rather attempt to do this: https://en.wikipedia.org/wiki/TCP_hole_punching

chisel is for bypassing firewalls, not for solving NAT traversal
Post reply on HN