Slashdot Mirror
TCP/IP Over HTTP
Nick Towers sends news of a nifty new RFC that has just come out - RFC 3093, the Firewall Enhancement Protocol, promises to reduce the hassle of setting up a firewall by tunneling any TCP/IP application over HTTP.
← Back to Stories (view on slashdot.org)
Floppy disks!
:-)
:-)
I bet it could be done with a module to the Linux kernel.
Seriously. You have a box with no network card or other connectivity except a floppy drive. You fire up Netscape and try to access Slashdot.org.
It writes the TCP syn packet to the floppy and beeps. You take the disk and put it into a box with real connectivity. It then reads the packet off the disk and sends the request. Slashdot responds and you have a TCP connection. It writes the confirmation to the disk and you take it back to the other box.
The unconnected box sees there's a connection and writes a packet containing the HTTP request. Then you take the disk over to the other box and it sends it and gets the responce. Probably the whole page would come without any further disk swaps, except the images.
So you take the disk, which now has the Slashdot home page, to the unconnected box and it gets read in via the TCP floppy stack. Netscape then requests the immages, so the Syn packets for those TCP connections all get written to the disk.
Repeat the previous couple steps for all the images. Repeat the whole process every time you access a story or other doc!
Heck, you could even do telnet connections that way, if you run the disk back and forth between every few words you type. And you wouldn't see what you type until you bring the disk back with the responce.
Question to kernel gurus: Am I correct in assuming that that would not be terribly difficult to implement? If I didn't have more important things to do, I'd almost be motivated to try it.
If you look at the IPP (Internet Printing Protocol, RFC 2567), you'll notice that it's a protocol designed to encapsulate printing in HTTP POST operations. The motivation for this? Ease of administration, since so many firewalls out there already allow HTTP out, it makes remote printing much easier for end users. Of course, the fact that HTTP is basically a client-driven, instantaneous response protocol totally inappropriate to things like delayed spooled printing and reporting of asynchronous printer error conditions hasn't ever stopped the IETF from forging ahead with this.
All hail the Printer Working Group!
Me thinks you're completely right.
Well, ok, the particular protocol is. But the reality is there are a staggering number of (slightly) more specialized protocols designed to do exactly this.
Very interesting how "well used/abused" (depending on your perspective) HTTP is, and how stupid many firewalling policies are.
I think this RFC is actually a parody of SOAP, as chronicaled in Bruce Schneier's June 2000 Crypto-Gram.
-"Zow"
Hmm.. Seems I forgot
RFC748 - Telnet randomly-lose option.
*sigh*
---
- RFC3093 - Firewall Enhancement Protocol (FEP).
- RFC3092 - Etymology of "Foo".
- RFC3091 - Pi Digit Generation Protocol.
- RFC2795 - The Infinite Monkey Protocol Suite (IMPS).
- RFC2551 - The Roman Standards Process -- Revision III.
- RFC2550 - Y10K and Beyond.
- RFC2549 - IP over Avian Carriers with Quality of Service.
- RFC2325 - Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
- RFC2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0).
- RFC2323 - IETF Identification and Security Guidelines.
- RFC2322 - Management of IP numbers by peg-dhcp.
- RFC2321 - RITA -- The Reliable Internetwork Troubleshooting Agent.
- RFC2100 - The Naming of Hosts.
- RFC1927 - Suggested Additional MIME Types for Associating Documents.
- RFC1926 - An Experimental Encapsulation of IP Datagrams on Top of ATM.
- RFC1925 - The Twelve Networking Truths.
- RFC1924 - A Compact Representation of IPv6 Addresses.
- RFC1776 - The Address is the Message. S. Crocker.
- RFC1607 - A VIEW FROM THE 21ST CENTURY. V. Cerf.
- RFC1606 - A Historical Perspective On The Usage Of IP Version 9.
- RFC1605 - SONET to Sonnet Translation.
- RFC1438 - Internet Engineering Task Force Statements Of Boredom (SOBs).
- RFC1437 - The Extension of MIME Content-Types to a New Medium.
- RFC1313 - Today's Programming for KRFC AM 1313 Internet Talk Radio.
- RFC1217 - Memo from the Consortium for Slow Commotion Research (CSCR).
- RFC1216 - Gigabit network economics and paradigm shifts.
- RFC1149 - Standard for the transmission of IP datagrams on avian carriers.
- RFC1097 - Telnet subliminal-message option.
Did I miss any?---
CmdrTaco et al can take pride in the fact that everything2 was cited as a reference in RFC3092 for its entry on "Prince Foo". I had my personal 15 minutes of fame last year with RFC2795 (reference number one, no less).
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
TCP via HTTP? Hah... see RFC 1149, "Standard for the transmission of IP datagrams on avian carriers", i.e. IP over carrier pidgeons. That one came out 4/1/1990. I also vaguely remember seeing something about TCP via UUCP on around this time of year in the mid-90s... TCP via UUCP would presumably have lower latency than RFC 1149, but still be a bit of a pain for interactive use.
"However, Firewalls are built to protect from external threats, not internal ones."
;)
Excuse me? I restrict what traffic is allowed outbound and require authentication on port 80 since it restricts most applications that aren't proxy aware.
Here's the issue. If someone were to get something inside the firewall, I want to make goddamn sure it doesn't make it's way back out. I'd rather deal with a situation where something has tried to get out but couldn't and then clean up the mess rather than wonder if something got out in the process.
That is all. Feel free to argue back
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
The AF on avian carriers beats this hands down.
Not to mention the follow-up RFC update with QoS
I didn't read the article, but I'm guessing (based on the rest of the comments here) that this is an April fools' joke. Regardless, this isn't all that interesting - HTTP proxies can already proxy random TCP connections. I don't remember the exact protocol, but you connect to the proxy and send something like this:
... and then anything you send through that connection to the proxy will be sent to the other machine, and vice versa. It's kinda neat. I don't know if this is a standard thing, but at least Junkbuster and Squid support it. Helped me out a bit before I had set up NAT and only had one box connected to the internet on my local network - I hacked up BeAIM to go through junkbuster :) Worked great. On a related note, this is why open source software is good. Otherwise I wouldn't have been able to use an AIM client (some might argue that this is a good thing though...)
CONNECT some.other.server:theport
Anyway, I don't think it would take a lot of voodoo to get the kernel to handle this transparently.
--
Great! Now I can tunnel into Internet Explorer!
Oh wait, that wasn't funny.
Its February 4th? Damn, that international date line thingy really isn't working well these days is it? :)
Come play Heroes of Might and Magic Mini online.
I guess they don't realize that some people actually do this? VTCP/Secure from Infoexpress does in fact have a mode that tunnels over HTTP.
RFCs 3091 (Pi Digit Generation Protocol) and 3092 (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.
It's a bug in Microsoft's development libraries. There was a discussion about it on Bugtraq, with a link to a FAQ . It's not a Y2K bug, so no one will bother tracking the productivity lost as a result, which is too bad, because it could be really big. And yes, changing the clock on your computer at work does count as lost productivity.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
RFC 2795 (Infinite Monkey Control Protocol) is by far the best RFC I've ever read.
You are so wrong. HTTP uses TCP. Therefore, TCP over HTTP would be fine, technically (if senseless)
As for your assertion that TCP could not be implemented on top of UDP anyway, think about this --- TCP is implemented on top of IP. IP is an _unreliable_ protocol as well. It's perfectly possible to implement a reliabl protocol on top of UDP or any other unrealiable protocol using the types of mechanisms TCP does.
(Although I was hoping for a goatse.cx story....)
----
"Here to discuss how the AOL merger will affect consumers is the CEO of AOL."
grep -ri 'should work'
Has anyone else noticed that /. has not changed their time in accordance with daylight savings?
Man is born free; and everywhere he is in chains.
I have seen firewalls that are overly strict, but they allow HTTP or HTTPS through them. If you have a host on the outside and a client on the inside, you can setup a PPP connection using stunnel between the two machines. Then you can do anything you like (including display a browser from the outside host back, run icq, etc. The cool thing is, if you use stunnel you can encapsulate it over https. This gives you the ability to have a secure, non-monitored, encryted connection to the outside host.
Goto www.stunnel.org and you'll actually find examples of tunneling ppp (and thus tcp/ip) over HTTPS.
--
Twivel
I'd go for a one-week orgy if there were no false positives. Given the circumstances, though, I'd probably just settle for two days worth.
43rd Law of Computing: Anything that can go wr
Of course, then I could see encrypting the http stream by encapsulating an ssh stream in it... Then I'd pick up my email via:
- POP over
- TCP encoded and encapsulated by
- SSH under TCP
- encapsulated within HTTP
- Transmitted over TCP
And pray that it's not being done on an appletalk or SNA network.Of course, trying to do UDP under these circumstances would be a travesty.
--
Free Software: Like love, it grows best when given away.
They originally called them Standard Time and Savings Time, but the abbreviations were too confusing.
--
Free Software: Like love, it grows best when given away.
Um, your resume is on your j: drive. This is obviously not internet accessible. Also, why not provide a version in HTML or PS? Word is a nasty proprietary format.
I'd like you to show the audience exactly what TCPv4 is. My bet is you'd find it a bit of a struggle. IPv4 yes, but TCP, probably not.
You are so wrong. HTTP uses TCP. Therefore, TCP over HTTP would be fine, technically (if
He's wrong, but, so are you (although in a much more subtle manner). HTTP is supposed to be transport independent. You could do it over a raw teletype if you wanted to. But when you use HTTP on the web, you are making TCP connections
Rate me on Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
Many wireless devices don't have TCP/IP, since it's not worth implementing it-- they're just there for HTTP, so they use an easier transfer protocol more suitable to wireless. That means, though, that on a lot of those clients you don't have TCP/IP, which certainly cuts down on hackability. This might be an easy way to implement TCP/IP, without having to hack their proprietary protocol. Yeah, it'd probably be slow as hell on a wireless e-mail client, but....
"Wanna see my resume? I'm looking for a summer job."
Hope you're not looking for a job in computers, but I wouldn't know because the link to your resume points to a file on your hard drive; probably behind an un-firewall enhanced firewalled system.
Or it could just be you don't have a webserver running on J:\.
Ace
Wait ... Spam does that now with the ask off questions.
we are doomed
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
IP over HTTP implementation:
http://www.nocrew.org/software/httptunnel.html
Sparks:Gadget:Beer Maker
1. . The idea behind it is that the units, days, months, years, go in ascending order of magnitude. The US system, in all its wisdom, uses an apparantly random order.
Ascending order seems backwards to me. When you name file versions by changing the date and you sort the files by name, then the files end up in some weird order. I name files using the descending order 01-04-01 (I guess today is a bad example).
The date format I use isn't mm-dd-yy because it's a random order. I use mm-dd-yy because that is what all of my coworkers, family, and clients use. I know that it bothers most people, but i _do_ live in the U.S. so I date things according to the way that the U.S. does it.
3. As far as your question goes, here's an answer: The US does it the way that they do because of what you said April, 02, 2001 -> 04-02-02. We didn't switch it back so that it would 'make more sense' in the same way that microsoft will never put the 'shut down' command anywhere but within the 'start' menu. People are just used to it.
By the way, mod me as a troll if you like, but Slashdot April Fool's addition sucks this year.
Keeping
You go to the doctor for a test to see whether you have a certain very deadly disease. One in a hundred thousand people have this disease. This test is 99% accurate and NEVER gives a false negative.
I know I'd spend my time figuring out how a test can be 99% accurate and NEVER give a false negative.
XML is a much better place to start because it already tunnels through HTTP (port 80). All that remains to do is establish a parser on the server side and a parser on the client side to convert the traffic back into TCP/IP.
But no matter what the approach, the overhead would mean this is only useful when all options have been exhausted. (e.g., You have an application that goes straight TCP/IP and cant be changed AND the firewall administrator will not open another port for you.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
it could give a false positive every now and again.
or something, just ignore me.. i'm going to go stare at a shiny object now.
end communication
It's daylight saving...no "s".
Er... Well, y'know. You can't make an omelette without um... destroying a forest. Or something.
My only political goal is to see to it that no political party achieves its goals.
Trolls throughout history:
Trolls throughout history:
Jonathan Swift
There are quite a few commercial products that use this trick.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
RFC 31337 you better recognize
360 degrees of Karma
Umm, this doesn't sound entirely out of the question to me.
They have something that does TCP/IP over e-mail, of all things. Getting into the network stack wouldn't be *that* difficult, unless you lacked root on the box. It seems less viable, though, when taking into consideration often environments in which strict Tcp access controls are implemented very rarely can administrator access be had on the users NT machine.
While it may just be an RFC, it still could be implemented. It struck me as kind of neat. What seems so outrageous about it?
mwtr / THIS SIG HAS BEEN PRAYED OVER AND MAY BE USED AS A POINT OF CONTACT (ACTS 19:12)
That's The April Fools Limitation Protocol. It can be very handy when implemented around this time of year.
Ok, ok. Don't get all worked up about it - it's obviously a joke. Here's what I found near the bottom:
3.4 TCP Header Compression
Compressing TCP headers in the face of a protocol such as this one
that explodes the size of packets is silly, so we ignore it.
4.0 Security Considerations
Since this protocol deals with Firewalls there are no real security
considerations.
5.0 Acknowledgements
We wish to thank the many Firewall vendors who have supported our
work to re-enable the innovation that made the Internet great,
without giving up the cellophane fig leaf of security that a Firewall
provides.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
On both counts (HTTP runs on TCP/IP and this is a joke) however he is correct that there are solutions to tunnel TCP/IP through HTTP and through other things. I know it sounds silly at first but there are many uses. I'll point out one of the more common ones, L2TP. Suppose I work at a major instutition and want access to their network from home. Well as it happens both they and I have phatty internet conenctions. Great, I can use those right? Errr, well except that is a security risk, since our data is sensitive. So, what do we do? Setup a virtual private network (using L2TP). Basically, I connect to a server at work using TCP/IP, then I and it establish a L2TP connection. Encapsulated in that encrypted L2TP connection is TCP/IP packets, that it then decrypts and routes tot eh corperate network. The point of the excersie is, of course, that I can use an encrypted stream to access the resources. The point of the encapsulation is that then EVERYTHING I do is encrypted, wether the application supports encryption or not. As far as all my apps know, they are communication via TCP/IP. However those TCP/IP packets are taken, encrypter, encaplulated in other TCP/IP packets, then sent out to the destination where they are reformed. As such I have created a network that is secure and acts like a private point-to-point link, but done it using the public internet and encryption.