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.
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 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.
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.
On the contrary, the only reason the internet works is because it's robust enough to survive incompetent network admins.
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.
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.
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.
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.
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.
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.
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.
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.