undefined | Better HN

0 pointspeterwwillis9y ago0 comments

It's almost exactly like TCP-over-DNS. Both are stateful protocols on top of stateless ones. The only difference is HTTP responses can essentially go on forever, whereas DNS ones are typically UDP with an upper bound on size, and TCP ones have a timeout on the order of seconds, and thus need to re-encapsulate further messages.

The biggest difference there is that while TCP-over-DNS just has TCP->DNS->UDP as overhead, the WS method has TCP->WS->TCP. Because the connection is stateful and the WS encapsulation is minimal, it's more efficient (and HTTP tunneling is almost always more functional than DNS or ICMP, anyway)

It's still inefficient. And it's not a raw socket, it's an application layer socket, essentially.

0 comments

2 comments · 1 top-level

icebraining9y ago· 1 in thread

Are you talking about WS itself, or this tunnel thing? Because I was just talking about WS itself, which doesn't have any TCP over it, it's just framed data over regular TCP.

Anyway, looking at the code of this tool, it doesn't seem like there's any actual TCP being tunneled; from what I can tell, the raw TCP terminates in the application, and the data is piped directly into the WS connection. That's why you have to choose a static target, whereas with a TCP tunneling system like iodine, you can use it as an open gateway.

Fair enough on the raw socket, I meant a TCP socket.

peterwwillisOP9y ago

I kind of jumbled the two things together in that comment, but WS itself is basically a stateful UDP over HTTP, so i'll compare it to that. (TCP has too many features to be compared to WS)

Comparing it to stateful UDP over DNS is a totally fair thing because in practice that is how you use it. You steal the ports of a completely different application to send data for your own different application, and do the hokey-pokey of one protocol before you then encode a payload in a completely different protocol before sending and after receiving it, and the application protocols it abuses to tunnel its data aren't even of the same state or connection mode.

Saying WS is "just framed data over regular TCP" is like saying stateful UDP over DNS is "just framed data over regular UDP". The only difference is that DNS has message reply limits. If you could keep sending one long DNS response payload, WS would be virtually identical to stateful UDP over DNS (when using tcp for the DNS).

And yeah you're right, this app is not encapsulating TCP packets, but it tunnels applications which use TCP. A lot of tunnels do this, although I don't think they advertise themselves as "tunneling TCP through X".

j / k navigate · click thread line to collapse