The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Getting around corporate firewalls for P2P application?

I am designing the protocol for a peer-to-peer application. We have complete control over the protocol that we use.

The application sends and receives streaming audio data. We have pretty well solved the problem of returning data packets through consumer and SOHO routers. (We use simple NAT punch-through for this.)

The next challenge we face is getting through corporate firewalls (which would include colleges, etc) that do not allow UDP traffic and only permit web traffic.

The bright idea I had is to open long lasting HTTP (port 80) connections, and to exchange data in both directions entirely within such sessions.

If an HTTP session died or was cut off without the "logical" session that we are administering being closed, the client (behind the firewall) would re-initiate the logical session by providing a hash key provided earlier to it by the server that uniquely identifies its old session. So we should be able to preserve the continuity of all "calls" until the client really wants to hang up.

I don't see any other way to work with highly restrictive corporate firewalls. What I am wondering is if even this approach is feasible, and how much content checking that corporate firewalls do of the data being passed.

Second question. Since this is our own implementation of a port 80 protocol, and we have no intention to allow web browsers to connect to us, could we get away with *not* MIME encoding the traffic? Or in order to be considered passable data to the firewall, would the data have to closely resemble normal web traffic?

Thanks for any advice and for discussing anything important I have not considered.
WannabeTycoon Send private email
Thursday, November 13, 2008
You're more likely to get away with it using 443 used for SSL connections.  Since the data is expected to be an encrypted binary stream, the firewall/proxy does not expect to be able to inspect it.  You would likely need to initiate a connection through a proxy using the proxy connection headers.

Good luck with breaking those policies! :)

Thursday, November 13, 2008
Add a disclaimer that "Use of this product in a corporate envirnoment may get you fired" if you really want to subvert the firewalls.
John Send private email
Thursday, November 13, 2008
Martin Send private email
Thursday, November 13, 2008
The first response about using 443 b/c it is not inspected is not true.  I thought the same thing when my dumb company cut off ssh access outgoing.  So I opened up ssh on 443 at home and got away with it for a couple of weeks.  Well turns out websense (which a ton of companies use unfortunately) DOES inspect packets and can tell the difference b/w SSL and SSH.  So I wouldn't count on port 80 and port 443 just going through without anyone noticing.  If they blindly use websense, they are getting the protection (censorship) for fres.
Spyplane Send private email
Friday, November 14, 2008
..unauthorized access would be unwise. Someone invested heavily into that infrastructure, complete with security.

I'd classify your application as 'malware', as soon as it steps out of it's restrictions. Although you might find a hole in the security (e.g., an unlocked door) doesn't mean that you're allowed to used it (entering without breaking)

Why not point out to the user that he is in a restricted environment? You might want to give the option to contact the network-admin to 'solve the issue'.

Good luck :)
Eddy Vluggen Send private email
Saturday, November 15, 2008
A lot of enterprise environments block all direct access to the Internet and force all requests to go through a proxy server. For example, the Active Directory may have Group Policy Objects in place that configure web access to go through the proxy server.

In most large corporate environments your application will never work and if for some reason it does work it is likely to bring down the wrath of the Network Operations team on your unlucky user if they do manage to get it working.

Contrary to what people may believe, large businesses do not spend millions of dollars on networks for the amusement of employees - these networks *will* be running business critical applications and they are therefore protected very carefully.
Saturday, November 15, 2008
Just use SOAP.

The entire web services concept is predicated on bad naughty administrators simply refusing to update the firewall configuration, and the collective response was to pretend that HTTP is the ultimate silver bullet protocol.

That has the advantage that in reality many idiotic managers hear "SOAP" and "web services" and can't see anything but buzzword compliance.  ;)

The real trick is to understand that geeks and managers have conflicting *but valid* viewpoints. Fine, they're getting in the way of your protocol and your protocol is good, but you're getting in the way of keeping the company safe, and keeping the company safe is also good.

If it's a legitimate business application and not another god-damned piracy tool, find out what your customers concerns are, and work with them instead of trying to sneak past them.

Sunday, November 16, 2008
I don't think "Just use SOAP" and "sends and receives streaming audio data" are particularly compatible.

I'm trying not to think what the resulting XML would look like on the wire... :-)
Monday, November 17, 2008
Here is a Java solution for SIP but the principles would apply to any language. A SIP proxy is the answer.

Monday, November 17, 2008
SOAPy audio?  Well, useful int he bathtub, I guess. (CDATA and some base64 encoding would do it, too.)  And it would be as sensible as most other attempts to work around the evil bad people who just won't open up the firewalls.

Monday, November 17, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz