Overloading HTTP

Posted Sep 22, 2012 10:25 UTC (Sat) by oldtomas (guest, #72579)
In reply to: Tent v0.1 released by job
Parent article: Tent v0.1 released

Yeah. It's what I used to call "multiplexing the whole Internet through port 80". Sad.

But yes, it's mainly the "crap about firewalls". At home, my ISP lets the things through I care about (didn't try more exotic things like UDP multicast, I don't expect it to work), but at $WORKPLACE, the firewalls are set up to just allow ports 80 (proxied) and 443 (CONNECT). I can understand that they consider a HTTP proxied port 80 somewhat more secure, because the proxy can try to trigger on known malware patterns (what about unknown malware?), but 443: you tell the proxy CONNECT blah.foo.org and there you go, an encrypted channel right through the proxy. Just more expensive.

Sad, yes.

And please, don't mention Jabber as a particularly good example. The sheer contradiction between streams (which are potentially unending) and XML documents (with an explicit beginning and end) has me split between weeping and laughing. There's lots of verbiage to that in the RFCs, but it doesn't make that better.

But hey, maybe some day network interface hardware understands HTTP headers and is unable to handle simple UDP.

Overloading HTTP

Posted Sep 22, 2012 22:46 UTC (Sat) by paravoid (subscriber, #32869) [Link] (5 responses)

Is incoming HTTP allowed from your corporate firewall?

Would your company policy allow you to host your own 24/7 Tent server in the company's premises?

The same applies to people who mentioned their (evil) ISP. Non-HTTP traffic still works fine on hosted servers or residential connections with static IPs, thankfully.

Overloading HTTP

Posted Sep 23, 2012 7:18 UTC (Sun) by oldtomas (guest, #72579) [Link] (4 responses)

"Is incoming HTTP allowed from your corporate firewall?"

No, of course not. I know what you mean -- but the point made was subtly different: my corporate firewall just does allow *outgoing* 80 and 443. Several (many?) ISPs seem to do that too. Thus, services "out there", having a "real" Internet connection make less and less sense if they sit on (say) port 22.

Overloading HTTP

Posted Sep 23, 2012 16:51 UTC (Sun) by man_ls (guest, #15091) [Link] (3 responses)

Egress filtering used to be my pet peeve: why limit outbound connections to certain ports? At some point clueless (or perhaps fearful) sysadmins started doing it to protect who knows what from whatever -- perhaps internal hackers from taking over FBI websites. Right now a sysadmin at any large company who left open e.g. outbound port 22 would be considered crazy by their peers, unless some Vice-Pope signs it off.

That particular fight was lost without having started, and now even home connections appear to have trouble connecting to certain ports outside the sanctioned range; not to speak about 3g connections. So we have better fight for having good port 80 support (e.g. for websockets), something where regular users are likely to help us -- if only by complaining loudly to their ISPs when weird layers of proxies and firewalls break connections.

Overloading HTTP

Posted Sep 23, 2012 20:13 UTC (Sun) by butlerm (subscriber, #13312) [Link] (2 responses)

Most ISPs I am aware of only block a small handful of commonly abused ports for outbound connections. A much bigger problem is blocking inbound connections. A real ISP (like CenturyLink) will sell you a static IP address that is completely unblocked, for a nominal fee.

I don't see how anyone can expect to operate a Tent server without such cooperation, so the protocol used for server-server communications is almost irrelevant. It is the client-server protocol where special consideration needs to be taken, and that will naturally be a web interface in most cases.

The idea that HTTP provides some sort of filter advantage for server-to-server communication, however, seems to be entirely a red herring.

Overloading HTTP

Posted Sep 23, 2012 20:54 UTC (Sun) by paravoid (subscriber, #32869) [Link]

Exactly my point. Thank you for making it clear.

Overloading HTTP

Posted Sep 24, 2012 19:45 UTC (Mon) by drag (guest, #31333) [Link]

> I don't see how anyone can expect to operate a Tent server without such cooperation

You have to have a connection brokering service for locating servers and setting up connections.

The idea is that your content server goes out and connects to a broker server. The user's clients do this also. So if their client wants to set up a connection with your server then it sends a message to the broker. The broker then communicates back to your server, which then pushes a hole through your firewall using a mechanism like uPNP or starting a fake connection to the client to open up a hole in the NAT connection tables for the client to connect through.

All in all this is a relatively routine thing used by a huge number of popular 'p2p' protocols.

I am sure that the 'Tent' people took this into account. Personally I think that a modified Jabber server would be good for this sort of thing.