Overloading HTTP

Posted Sep 23, 2012 7:18 UTC (Sun) by oldtomas (guest, #72579)
In reply to: Overloading HTTP by paravoid
Parent article: Tent v0.1 released

"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.