Please create an account to participate in the Slashdot moderation system


Forgot your password?
The Internet

TCP/IP Over HTTP 126

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.
This discussion has been archived. No new comments can be posted.


Comments Filter:
  • by Anonymous Coward
    Because TCP/IP over HTTP was so fucking subtle I could have beat you over the head with it.

    In fact, theres still time. Open the door when I knock, theres a good chap.
  • 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

    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. :-)
  • I havn't tunneled full tcp/ip, but I often set up services on http/https ports to get past a certain over-restrictive firewall. Gotta wonder what the people at the network center are thinking when they see an ssl connection open for 4 hours.
  • by Phaid ( 938 ) on Sunday April 01, 2001 @02:40PM (#322157) Homepage
    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!
  • RFC 31337 [] you better recognize

    Now, *that* was *really* boring...

    I think not; therefore I ain't®

  • Me thinks you're completely right.
  • jesus christ, enough man
  • 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.
  • by "Zow" ( 6449 ) on Sunday April 01, 2001 @02:31PM (#322162) Homepage

    I think this RFC is actually a parody of SOAP, as chronicaled in Bruce Schneier's June 2000 Crypto-Gram [].


  • no no, we can't have worthwhile news any other day, why not have completely worthless news today? I mean, hell, let's go back to the past 3 April Fools and see if we can't repeat some of those fucking posts, maybe they were funnier.
  • Hmm.. Seems I forgot
    RFC748 - Telnet randomly-lose option.

  • by demo ( 8301 ) on Sunday April 01, 2001 @01:28PM (#322165)
    Just to sum up most of the April Fools RFCs over the years...
    • 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?
  • Not really. I've bored my collegues with my complaints about the stupidity of system adminstrators more than once, and these complaints all went exactly along the lines of the fake RFC.

    I've you're a hacker that wanted to continue sending secret information from within a firewall to outside the firewall, they could do exactly what the RFC described (the may save some time by simply sending it to some CGI script, but implementing full IP is certainly an option)

    Firewalls, on outgoing connections, really provide no security at all, but make any kind of efficiency in a new IP-based protocol impossible :-)

  • What about httptunnel []?
  • Great idea guys, right along the spirit of WebDAV. The unfortunate part is, that you efforts will be defeated with a software upgrade for firewalls from vendors. ...... inconvenienced). Firewalls work, and have a place in the Internet. However, Firewalls are built to protect from external threats, not internal ones. Our proposed protocol does not break the security model of the Firewall; it still protects against all external risks that a particular Firewall can protect against. For our protocol to..... I find this statement most troubling. A firewall protects the outside, and the inside. The firewall protects the outside by preventing external intruders from gaining unauthorized access to the internal network. The firewall also protects employees from themselves in many cases by keeping them from using unauthorized services that may 1, bring the network to its knees by crunching the bandwidth available. Or 2, By stopping a sabetour/employee from committing industrial espionage. If you firewall traversal protocol went through. It wouldn't allow more invoations. It would just cause firewall companies to upgrade their software to screen the packets on port 80 for only true web traffic. That is all. Firewall vendors support you because, you will force companies to pay for costly major upgrades to their firewall.
  • 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).
  • 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.

  • If you live in the pacific time zone, you could choose Pacific Standard or Pacific Daylight in your preferences.

    Guess what the "Daylight" means?

    (actually, you could choose a lot more than those, but I don kno whi yod wa-whallaballa bing bang shleebin gurkin flam, flam, flam, flam,



  • And the Japanese who also put the year first.
  • "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 ;)

  • I'm laughing.... are you a troll?
  • The AF on avian carriers [] beats this hands down.

    Not to mention the follow-up RFC update with QoS []

  • "JSockets []® is a general purpose 'firewall tunneling' product used to deliver Java applets and business objects from the application server to the general Internet. It provides full-duplex communication support and allows a client to listen for connections from other JSockets clients. Essentially, we have rewritten TCP/IP to run over HTTP."
  • 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:

    CONNECT some.other.server:theport

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

    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.
  • by ajakk ( 29927 ) on Sunday April 01, 2001 @12:56PM (#322179) Homepage
    Its February 4th? Damn, that international date line thingy really isn't working well these days is it? :)
  • Actually, I have a friend who used to teach programming in Turkey back in the early days of the 'net. At that time, the entire _country_ was connected to the rest of the net via a 9600 baud link to Germany. The servers on either end would get so backed up that occasionally (every week or two) they would offload the entire mail spool onto tape and snail mail it to the other end where it would be loaded back onto the network.
  • by ryanr ( 30917 ) <> on Sunday April 01, 2001 @12:45PM (#322181) Homepage Journal
    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.
  • I do believe I have been inspired... I am going to begin coding immediately and the entire implementation shall be written in.... ash!

    Parrot is obviously the language this should be implemented in!
  • by James Lanfear ( 34124 ) on Sunday April 01, 2001 @12:50PM (#322183)
    RFCs 3091 [] (Pi Digit Generation Protocol) and 3092 [] (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.
  • dont you mean january 4th?

    use LaTeX? want an online reference manager that
  • hell i was referring to this sentence:

    wasn't there some rule about not making jokes past midday on 01-04?

    use LaTeX? want an online reference manager that
  • 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.
  • So I can run Java VM on NT on Solaris on Linux on NT on Solaris. Then I symlink /dev/random to a cron script that submits stories to /.

  • of course you realize that, at this point, depending what media you're transmiting this over, you can't fit anything more than headers into a packet. and maybe not even that.

  • by GuavaBerry ( 50743 ) on Sunday April 01, 2001 @01:25PM (#322189)
    RFC 2795 [] (Infinite Monkey Control Protocol) is by far the best RFC I've ever read.
  • What's more is, and I'm sure somebody could argue this; but HTTP uses UDP connections. The entire TCP/IP Protocol suite requires TCP connections which are more complicated than simple UDP - using HTTP a true TCP connection is impossible.

    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.

  • I just want to throw in my $0.02 and say that this year's crop of April Fools stuff is as good as if not better than any other year's, because it's all very subtle and isn't obviously false when you first read it, and because it shows that the entire Slashdot staff have not let success go to their heads and can laugh at themselves. Great job, guys.

    (Although I was hoping for a story....)
    "Here to discuss how the AOL merger will affect consumers is the CEO of AOL."

  • You mean the 31 Sunday in March? I had that problem today on one of my Windows 98 SE boxes, but this is the first time it has happened on here. Really strange.... Any ideas?
  • Has anyone else noticed that /. has not changed their time in accordance with daylight savings?
  • Wait a minute...let's look at those odds again:

    1 out of 100 tests is inaccurate. No tests give a false negative. That means that, out of every 100 tests, 1 is a false positive.

    Out of every 100,000 tests is a true positive.

    By a, 1,000 out of every 100,000 tests will be a false positive.

    Therefore only 1 out of every 1,000 people who test positive will have the disease.

    So, in other words, I'm going to get the same number of projects done as I was before--none of 'em!

    Wanna see my resume []? I'm looking for a summer job.

  • Grrr....remind me to apply a cluestick to FrontPage at the earliest convenience. The problem, quite simply, is that our "wonderful" personalweb server is no longer accessible to post via any method other than FrontPage (so far as I can certainly isn't SMB-accessible anymore). So I'm limited to posting with FrontPage, which leaves me somewhat at its mercy for links...grrr....this is why I like Emacs much, much better for HTML tasks.

    granted, I am a blooming idiot for not checking that first, but I threw the page up in .5 seconds while I was in a lab (no FP on my personal PC, thank God) and forgot that FrontPage likes to do things like that.

    Why no HTML? It's not a layout language, and all the people I've talked to have preferred either Word or PDF format.

  • Okay, I now have my resume [] up on my box, rather than the local "personal page" server. That should work (no FrontPage involved this time).

  • Actually the US system makes more sense to me; the first number tells me exactly which piece of the year i'm dealing with. If i'm putting something on my calendar, i go to the correct month FIRST. Then i find the day. The day being first to me is meaningless, b/c i don't know quite where it goes yet. At least, thats my thought process.
  • I would hope most companies have a program runnign to sync the time with a master server.
  • Your link to RFC1313 is either slashdotted or broken.
  • SOAP tries to shovel everything through port 80 because it's open to firewalls...

    ...and they are serious!!!

  • My brain is dribbling out of my ears ...

    Thankfully, desktop supercomputers like the one mentioned here [] exist to carry us into the brave new world of security by massively recursive recursion. :)

  • by twivel ( 89696 ) on Sunday April 01, 2001 @01:54PM (#322202)
    While this RFC may indeed have been designed as an april fools joke, there is indeed a need for such a thing.

    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 [] and you'll actually find examples of tunneling ppp (and thus tcp/ip) over HTTPS.


  • No, with TCP there doesn't have to be a one to one relation between packets. Actually, with TCP you don't even have much control about wich data will be put in which packet, since the TCP/IP stack will take care of this and splits the stream into packets.

    Oh, and BTW:
    IP has the function to fragment large packets.
  • Hey, I just found a way to tunnel HTTP over TCP! Oh, wait. Never mind.
  • Compaq Australia had a good one last year too. They took out a big full colour advertisement in the Sydney Morning Herald (one of the more respectable newspapers in Sydney) advertising a new technology for their laptop computers, to charge themselves by dialling up to the internet and using the power from the phone line to charge their batteries. It was really quite clever and had me going for a while. It's great to see that they had the balls to do it on such a grand scale too.
  • I agree. While this is an attept at humour, it would make sense if such a tunnelling RFC existed. Weblogic tunnels their t3 protocol over http so that you can connect to EJBs from applets. There are many uses for tunnelling TCP/IP over HTTP.

    And yes, I know that HTTP runs over TCP/IP. SSH runs over TCP/IP and it does TCP/IP tunnelling. Damn handy as well. Removes a lot of the NAT problems with VNC, while encrypting your connection.

  • 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
  • Just remember, in order to truly understand recursion, we must first understand recursion.

  • What's so nasty about the idea of TCP over HTTP? It's been done with the SSH protocol -- sometimes for similar reasons. (though with SSH, it's a little bit more likely to be done legitimately than I would expect with ssh).

    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.

  • It's daylight "s".

    They originally called them Standard Time and Savings Time, but the abbreviations were too confusing.

  • Actually I believe this would be possible, but totally useless. You could possibly develop some sort of queuing system that be able to "qeue" incomming / out going packets. then make it alternate with PUT/GET requests. Again this would serve no real purpose. Anyone else? could this be possible or am I too stoned to relize that it isn't?
  • What's daylight? And why are we trying to save it?
  • I think we've read enough bull for one April Fools. Isn't there any REAL news that's actually true?
  • I know almost nobody will read this, but don't miss the other RFCs released on April 1st, 2001. True gems like the Pi Digit Generation protocol [], that states "One REQUIRED PIgen service is defined as a stateless TCP service. A server listens on TCP port 314159.".

    And also, don't miss this very interesting RFC called the Etimology of foo [], with more than useful information about the foobar!

    At least, these are _technical_ April Fools jokes :-)

    You're tired of Slashdot ads? Get junkbuster [] now!
  • 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 dumbass those links just point to a drive letter. I'm sure as hell not hiring you.

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

    Hmm, I think maybe that is the point. That companies deploying firewalls should just give up on trying to protect against such things?
  • generally speaking... wouldn't you send your http information over tcp/ip... soooo... why would you go through all the trouble of trying to get you tcp/ip data into an http data which is going over tcp/ip... to me, this just sounds like a complicated solution to a simple problem. It's probably going to cause more problems in the process as well. And man... how big is the stack going to be when everything is done too?

  • OK, now I realize, it was suppose to be funny. Gee, when did I lose my sense of humor?

  • i dont know enough about either tcp or http, so i have to ask, could you even encapsulate tcp in http when http is stateless?
  • So someone set up a server (for a fee) for those poor @home users (they're behind really bad firewalls, right?)...

    You can run PPP over GNU httptunnel []. The same thing, really, but no joke.

    /abo (10 Mb/s Ethernet internet connection straight to his home, and no freakin' firewalls!)

  • 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 []
  • 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....
  • I like that the email address was
  • hehe I had to laugh when I read this:

    TCP_UP - The 16-bit TCP Urgent Pointer, encoded as the hex representation of the value of the field. The hex string MUST be capitalized since it is urgent.
    Heeehehehe... I can just imagine someone actually reading this and trying to immpl. it hehe.. oh the horror. ;)
  • Maybe we should mod up troll posts to +5, haha, that'd be a funny April Fools! Well, at least funny when compared to the Slashdot postings. :)
  • "... but HTTP uses UDP connections ..."
    No, it uses TCP. Furhter, there are no "UDP connections" because UDP is a connectionless protocol.

    Still, it would certainly be possible to tunnel TCP over UDP just as it is possible to use IP as the transport for TCP.

    Someone of the German computer magazine c't even experimented with TCP-over-DNS. (The background is that a company provided a toll-free 0800 number for IP access but with firewalls so that you could only access support web servers ... and resolve arbitrary domain names. No, it wasn't an April issue.)

  • You can already do this with SECSH and PPP.

    It's an April Fools Joke. The RFC was written 1, APRIL 2001. It is not written well, and it was obviously done in a hurry.

    It mentions many times over that "we respect the right of people to use a firewall"; yet the RFC proposes circumventing a firewall completely at every level. It is a JOKE.

    What's more is, and I'm sure somebody could argue this; but HTTP uses UDP connections. The entire TCP/IP Protocol suite requires TCP connections which are more complicated than simple UDP - using HTTP a true TCP connection is impossible.

    The pranksters are probably network admins themselves, and thought it would be funny to write an RFC that claims employees on an internal network are actually smart enough to decide which of their programs are good - which is why the mention, "Best of all, no need to bother a network admin".

    Just thought I'd mention it so I can start hating every idiot who posts on this one. []
  • "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:\.
  • Listen up people this is the next big thing! Although it's still in draft the idea is to print packets on A4 papers and mail them to destination, reassembe and scan... the best thing is that it can switch to a special mode to send emails! I think I should patent it... Edo
  • Flame on
    How 'bout ditching TCP/IP in favour of ATM?
    Flame off
  • "2001 aprilis 1": that's how the Hungarians say it. "2001/4/1" is the shortened form. Consistent with what they say, and consistent with the direction of time as we feel it. Too bad it's only the Hungarians.
  • Either this becomes the ultimate in recursive protocols, or else this the start of a plot to take down by using it to to create a massive series on infinite loops between home computers and the rest of the planet.

    Wait ... Spam does that now with the ask off questions.

    we are doomed

    Check out the Vinny the Vampire [] comic strip

  • It would be a huge security problem to say the least. Virtually uncontrolled outbound traffic.
  • Write an RFC, they'll probably publish it next year. If you have time today, submit it to this thread!
  • by Idolatre ( 197068 ) on Sunday April 01, 2001 @12:48PM (#322239)
    Daylight saving is an april fool, DON'T DO IT
  • Yeah - worse still, it's 6:54am 02/04/01 here in Australia... Somebody tell'em it's bad luck to make April Fools jokes when it's no longer April Fools day...

    wasn't there some rule about not making jokes past midday on 01-04?

  • It's funny how the rest of the world likes to point out their differences from the United States and make it sound bad that we do things differently. I have a few comments about your post:

    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.

  • 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 ~~
  • 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.
  • It's daylight "s".
  • by NonSequor ( 230139 ) on Sunday April 01, 2001 @12:44PM (#322255) Journal
    I can run TCP/IP over HTTP and then run HTTP over that, and then run TCP/IP over that, and then HTTP, and then run TCP/IP over that, and then run HTTP over that, and then run TCP/IP over that, and then run HTTP over that, and then run TCP/IP over that, and then run HTTP over that, and then go into an infinite recursion.

    Er... Well, y'know. You can't make an omelette without um... destroying a forest. Or something.

  • There's a bug in Win95 that doesn't change Daylight Savings this year until next Sunday.

    Trolls throughout history:

  • A lower overhead method of achieving the same effect is to use SSL. This has the additional advantage that the encryption protects against countermeasures by the firewall admin.

    There are quite a few commercial products that use this trick.

  • RFC 31337 [] you better recognize
  • 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?
  • 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

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

If graphics hackers are so smart, why can't they get the bugs out of fresh paint?