A guy I know once had a job enabling TCP/IP over port 80 for extremely slow and very poor connections (for things like cement mixers in the middle of Brazil that have horrible connectivity but need to be able to transmit when and where cement might be needed). It seemed to me that this just enables another attack vector to bypass just about any network based security measure.

- RSnake
Gotta love it. http://ha.ckers.org

that why port 80 is the Universal Firewall Bypass (UFBS) as "mike andrews" called it in his talk about web app security at good. You need the service so you cant sacrifice closing the port in order to kill usability like web servers for example.

trix

It's not just inbound that I'm worried about. Sure, inbound is a problem but it's a problem that many websites have dealt with (XSS/CSRF aside). It's outbound requests from your users that's especially nasty. And if I can now tunnel any TCP/IP requests over port 80, and have some tool sitting behind the firewall to capture and do something with that traffic it seems like that's yet another way to enable networking attacks via port 80 - in a very crazy sort of way.

- RSnake
Gotta love it. http://ha.ckers.org

Hey rsnake, actually thats a very ingenious and great idea.

http://hackathology.blogspot.com

You mean in the DMZ RSnake?

(demilitarized zone FYI)

I'm not sure what you're asking jungsonn? This is more of a client to server thing, not a server to server, although I suppose you could make it client to server to server, but for it to be effective it would have to tunnel all your packets on any port, not just port 80 making it really a requirement to have it either a client side application or a proxy that turns all TCP/IP packets into HTTP packets. It doesn't really have to reside in the DMZ, but the listener on the other end would, otherwise you couldn't route packets to it.

- RSnake
Gotta love it. http://ha.ckers.org

There's an RFC about this: http://www.ietf.org/rfc/rfc3093.txt

:)

Anyway, I see two cases:
1) An attacker has owned a server. In this case all is lost; you're owned.
2) You implement some server that tunnels [tcp/ip] over [tcp/ip + custom protocol on port 80]. In this case, the firewall isn't bypassed, it's just moved. The server needs to support firewall features, or the hardware needs to be arranged such that:

[Web Access] <-> [Firewall:80] <-> [Tunnel Server] <-> [Firewall:?] <-> [Protected computers]

And actually, for extremely slow and unreliable connections you want to send less data, not more, so using a tunnel of any sort just exacerbates the problem by increasing the amount of data to be transmitted. Unless I'm fundamentally misunderstanding what you are describing, this makes no sense for the scenario you presented.

-kogir

even worse, since TCP over HTTP means sending packets over an insecure network, everything is readable. You can transmit over SSL over TCP over HTTP but you'd still need a set of pre-shared keys. Ugh, this is way too complicated.

- RSnake
Gotta love it. http://ha.ckers.org

Well, isn't the solution a IPsec VPN then?

No, because the caveat is you cannot use anything other than port 80. Unless what you are asking is can you put IPsec VPN over HTTP, in which case, yes, but that's a whole huge level of extra complexity (probably needed complexity, but still).

- RSnake
Gotta love it. http://ha.ckers.org

The destination port is used to route packets on a server to the appropriate network application. For example, port 80 is the standard port number for HTTP traffic, and port 80 packets are processed by a Web server. Destination ports are typically well-known ports (0-1023) for common Internet applications such as HTTP, FTP and SMTP. It can also be a registered port (1024-49151) that vendors use for proprietary applications.

So this is not just tunneling another higher level protocol over port 80 to get to the open port? But actually recreating TCP/IP as a series of http requests/responses? Wait, so you need TCP/IP to run http... then you're going to rewrite TCP/IP to run on top of http? And this was done probably because there was a corporate policy saying "only port 80 can be open."

It does make me curious whether anyone has ever made http work over another layer 3 or 4 protocol. IPX? UDP / ICMP?

UPNP is HTTP over UDP, I'm sure three are other examples. Technically HTTP can go over any IP protocol.

-id

@id - Interesting, thanks. I just wondered if anyone had ever used it for anything.

UPNP is used all over the place!

search for HTTPU, I'm sure you'll find plenty of stuff it is used in.

-id