Hacker News Reader

So we tunnel everything through 80/443, and then proxies are going to deep packet inspect that, and selectively block some over-http protocols, so we're going to tunnel stuff through a more innocuous looking protocol over HTTP, and tunnel through the tunnel through the tunnel through the tunnel.

I propose OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP as the new de-facto standard connection protocol. Maybe we can FTP through that VPN connection some time, please wait while I cook up a JavaScript FTP/OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP client.

Every 5 years the concept of the application port will be re-invented at the higher level of the stack.

Looked like a good idea until you mentioned JavaScript. Bummer.

If you're so against a js client, you could certainly whip one up in another language...

Whoosh...

EDIT: A OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP is a terrible idea and I'm assuming it was meant as a joke. Thus, the addition of Javascript to the comment makes no difference at all. Thus, my comment was intended as a joke since it's irrelevant (again) in which language a bad proposal is implemented.

There, you took all the fun out of it. Happy? ;-)

If it's any consolation, I laughed harder at this than I did at the original joke.

I guess I'm naive and think that comments on HN should try to be constructive, so your sarcasm did miss me.

If the proposed idea is a bad one, don't you think it would have been much more helpful if you added your opinion on that to the convo rather than snark?

My apologies for ruining your fun.

The original "idea" itself was itself sarcasm. Your parent was simply underscoring it. You just failed to identify the original sarcasm, and ended up confused and a bit too serious about it all. It's just some obscure humor, no need to get worked up over it :)

Actually, I didn't get it at first and now I think it's pretty funny :-)

So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP.

And thus naturally HTTP must be made to accommodate for all those applications.

You may think that makes sense, but you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence.

Besides, if that's the path we're walking, DPI-based firewall with HTTP-level application firewalling will become the new norm, and we've gotten nowhere further. Except we now have a even bigger mess to work with.

While the OSI-model may be going a bit over board for some aspects, making all future application-protocols be a squashed through HTTP is madness. This thinking is of the same quality and mindset as of PHP developers.

> So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP.

The product I work with has some protocols that is non-http. Some of our customers are complaining to us because _their_ users can't get through their own firewall (i.e the users own firewall, not our customers firewall). These users are often on corporate networks, and to get the users to convince their employer to fix their firewall is likely a waste of energy. In fact our customers may consider to switch to another vendor if we don't change to a HTTP based protocol.

Of cause the same firewall administrators may introduce deep packet inspection to only allow real web traffic later, creating more problems, but as someone delivering third party solutions now, you are forced to use HTTP or HTTPS.

> you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence

On the contrary, the only reason the internet works is because it's robust enough to survive incompetent network admins.

I did not say that. What I am saying is that applications of the future that tunnel over HTTP will be much, much wider adopted than those that don't. Regardless of how suitable it is for the purpose. I'm not saying this imposes any constraint on the HTTP designers.

Tunnelling will probably have to be HTTPS everywhere too as a countermeasure against both surveillance and DPI.

Arguably the internet is a hack around incompetence and power-hoarding; the phone companies potentially had the technology to deliver many of the things we see as internet services as early as the 1980s, but were too bureaucratic to deliver innovation and especially cost reductions. (Compare MINITEL, for example)

That the internet makes service-based billing hard is also a feature.

> you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence

The right half of your brain is wired to the left half of your body (and vice versa). That's just the standard, go-to, basically harmless example of stupidity in the design of long-lasting systems.

From http://uncyclopedia.wikia.com/wiki/Unintelligent_Design :

> Unintelligent Design is the theory that the world was designed by some higher power, but this higher power did a piss poor job at it. There are many theories as to how the universe could have been so stupidly and half-heartedly spilt into existence.

Or from the slightly more serious http://en.wikipedia.org/wiki/Unintelligent_design :

Your optic nerve originates at the front of your retina and pierces through it, instead of more sensibly originating at the back:

> The retina sends electrical signals to the brain through the optic nerve and people see images. The optic nerve, however, is connected to the retina on the side that receives light, essentially blocking a portion of the eye and giving humans a blind spot. A better structure for the eye would be to have the optic nerve connected to the side of the retina that does not receive the light, such as in cephalopods.

You stupidly breathe through the same tube you eat and drink with, causing a staggering number of unnecessary deaths:

> If the [pharynx and larynx] were not connected and did not share a portion of their travel paths, choking would not be an issue, as it isn’t for most other animals in the world.

I think people are missing your point: Human beings seem to be built based on hacks around incompetence, yet we've made it for quite some time, it's not a great point but nevertheless makes sense.

That's one of two points. Indeed, humans are a much, much longer-lasting system than the internet. But you can also think about why these kinks in the design of living things arose in the first place; as wikipedia nicely points out, a lot of glaring mistakes in one animal work the way you'd expect in other animals. The "mistakes" arise because they're the fastest way to produce a desirable result, and they persist for great periods because making changes to a working system is very hard. In a certain sense, history does show that adding hacks on to the "outside" of a working system, so that it stays working at all times, can be a superior strategy to trying to revamp the whole thing in an elegant manner.

If we're going to pull on evolutionary biology metaphors, I think the "Red Queen Hypothesis" is the more apt one for this situation...

HTTP is an arms race? Between what and what?

Until a big enough player decides to use something else.

Case in point: 5223/tcp, used by Apple's Push Notification service (amongst other things). Push notifications not being delivered to so many networks made their users angry and tech support calls (and costs) boom, and had soon 5223/tcp unblocked, even on free, non-encrypted, coffee-shop wifi networks.

I understand that most developers just choose to roll with it these days, but I really believe that putting everything atop of 443/tcp because of clueless/incompetent sysadmins is a huge mistake.

Keeping protocol stacks small, efficient and secure should be a design goal.

> because of clueless/incompetent sysadmins is a huge mistake

I think clueless is a little strong. We've just gotten to a time where the usual connection between network administrators and users is pretty loose. You don't actually know who is running that coffee shop wifi, so you can't ask for your applications to be unblocked.

Here's why I think firewall punching is stupid and should not be supported.

IP addresses are logical numbers used to communicate with a host. In order to make it easier for humans to know what host to communicate with, DNS records were created to be able to easily communicate with a particular host.

In addition to figuring out what host we want to communicate with we need a way to specify what application we want to use. So service names were created and assigned to a static list of application port numbers. Two of these application service names are "http" and "https", which each provide a different application protocol.

We've built so many things that depend on these two application protocols that developers have finally outgrown what the protocols are capable of. But to get support for a new protocol is "hard". You have to do three things to successfully roll out a new application protocol:

1. Write a server for it and make people want to use it, 2. Write a client for it and get users to want to use it, 3. Get network administrators to open up their firewalls to support it.

Sadly, many developers are playing a cat-and-mouse game with network administrators. They want their applications to be used by anyone, anywhere, automatically. So they employ tricks to get their content past network administrators, like re-using the same application service names used by protocols which are ubiquitously supported throughout worldwide networks.

But this just creates an arms race with network admins. For example, mandating strong encryption to use a service means a network admin traditionally can't restrict what kind of applications work over it. So in order to fight their users subverting their approved applications policies, more and more organizations are doing SSL inspection by injecting CA certs into their employees' computers to block unauthorized applications.

Fighting network admins is a losing game, and does not benefit the users of your applications, or the developers. Instead of hiding more features and overlaying protocols, it would be more productive to create protocols that use their own service names and provide their own functionality and let users demand it be supported by the network admins. This is how all popular application services have been adopted over the years and provides the best quality of service to everyone involved.

On the other hand, there are firewall administrators who do extensive filtering on ports 80 and 443 and allow other outgoing traffic by default. We get pretty ticked off when some thermostat, credit card machine, or postage meter decides to send its bizarre and undocumented data stream over port 80 or 443 in the name of firewall compatibility and therefore becomes incompatible with our firewall. (Yes, we can put in exceptions for those machines' IP addresses, but if they didn't try to use HTTP ports, they would Just Work.)

Let me tell you that where I live, networks like yours are the minority. Sadly, when 99% are going for the 80/443 are free and the rest forget-about-it, I'm going to "tunnel" my stuff over 443 because I don't like being called 10-20 times a day with "nothing works"-type complaints that I can't properly remotely debug because obviously, nothing works.

Edit: my "tunnel" is actually WebSockets over SSL on port 443. Not sure if you guys would block that as supposedly this should be no different from, say, gmail or facebook traffic.

Yes, websockets should be fine. Making my proxy support websockets was a little difficult, but I think it works now.

If the traffic is compliant with the protocols that ports 80 and 443 are supposed to use, it's not a problem. The one that really gets me is a thermostat using a proprietary protocol over port 443. This protocol is one where the server sends the first data over the connection; in TLS the client always sends first. So my proxy was just waiting for the TLS client hello while the thermostat was waiting for its server's message. If the thermostat had sent something first, the proxy could have seen that it was invalid TLS and passed it through; instead it deadlocked.