Hacker News Reader

Comment by BillinghamJ | Hacker News Reader

Why? The entire point of ports is so you don't have to do this.

Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.

There are a number of work and wifi proxies which won't allow out a lot of traffic, based on port. A multiplexer like this can work around such (assumed) well-intentioned but poorly implemented protections.

Wouldn't a VPN or tunnelling solution be better? You pass all your traffic through a fixed port on one host, then unwrap it and use the web as though the restriction wasn't there.

VPN or tunneling solutions are unlikely to work if severe network restrictions are in place. e.g. firewalls that only allow TCP ports 80 and 443.

Nothing stops you from passing a VPN through a TCP connection on port 80 and 443. There are few protocols people haven't tunnelled IP over (DNS included...)

I often have to work behind "smoothwall". AFAIK, it only allows HTTP over port 80 and HTTPS on port 443 - any other protocol on any other port gets blocked, including other protocols over port 80/443.

To bypass this, I wrote a simple ruby script to tunnel TCP connections, while adding fake HTTP headers to get through the firewall.

With only a bit of extra state-machine glue, you'd have a clean and standards-compliant websocket-based VPN.

Can you share that script?

obfsproxy with obfs3 as a pluggable transport does somthing similar, it's made for tor bridges but i'm sure you could use it for vpn traffic too.

https://www.torproject.org/projects/obfsproxy.html.en

https://gitweb.torproject.org/pluggable-transports/obfsproxy...

Actually, yes, packet inspecting firewalls do. Hence the SSH over TLS, to make things stealthy.

Generally these well-intentioned networks block the usual VPN and tunneling solutions (think kid and a school network with a firewall that only allows FTP, HTTP, and HTTPS).

At which point you simply use these ports for your VPN.

OpenVPN can use TCP, it can use UDP, it can use whatever port you like, it can even use a fixed key to turn all traffic into random noise (obfuscating protocol structures).

Thus the value of having a multiplexer which allows you to run these on 80 and 443, while still running a web server.

Doesn't even have to be that nefarious - I am blocked from using my OpenVPN tunnel (UDP and TCP) from at least two restaurants that I'm aware of.

Deleted comment

"Those who sacrifice connectivity for bourguignon deserve neither." -- Internet Ben Franklin

Yeah, but these well intentioned networks also often do packet inspection to block simple workarounds.

SSH with SOCKS5 tunnelling enabled does exactly this. The trick is that VPN's aren't allowed very often, so that's where the TLS tunnel trick steps in. You can use a VPN over TLS with serve2d if you want. I just find ssh -D5000 easier to set up quickly "in the field" than a VPN, especially seeing that it doesn't require server configuration.

Different, but not better depending on your requirements. Tunneling over a VPN can be pretty slow.

It's not a bad idea, though I'm not sure why someone would want to do this on their own in a bolt-on manner. For an example of a place where demux is encouraged, see RFC 6335:

Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. [...] IANA strives to assign only one assigned port number per service or application.

Why do I know this? Consul by default uses 5-6 ports, and one of them conflicts with an IETF registered port in-use by our data center provider. Was hoping that the RFCs gave some ammo for a resolution in my favor, came out more humble and wondering if Consul really needed that many ports.

Modern apps seems to do their best to require lots of ports numbers, often with very little justification. It's incredibly annoying.

Some of it understandable, e.g. when one port is for stuff that is always meant to stay behind your firewall, and another for public access. In that case it actually makes things easier to do properly. But so often it appears to be entirely gratuitous.

> Why? The entire point of ports is so you don't have to do this.

There are use cases - many nefarious cases but some real world cases.

Let's say your university allows everything through 80 but blocks everything else. You could SSH home or stream content.

Another use case could be that you have a web site and game server on same server. An interesting implementation could be to listen on port 80 so that they could connect to yourserver.com via HTTP and view information about the game/server and connect on the same port. Interesting but not very practical.

I suppose an acceptable/respectable use case would be custom load balancers or honey pots.

Well, back in highschool I used to use a similar idea to run SSH to my home PC via port 80 -- the network restrictions meant a VPN wouldn't work, and it was the only way to get access to run compilers I wanted to play with without relying on exploits to get around the system's restrictions.

Blocking all ports but 80 and 443 is "the firewall" and therefore a very large component of any enterprise security policy.

Reply on news.ycombinator.com