Not Your Father's TCP/IP Stack
I sometimes hear of people talking about controlling TCP and UDP ports, as if that is the battleground for network access in 2007. Reality check -- that hasn't been true for years, unfortunately. Boy, I miss those days -- the days when defined applications used defined ports and blocking all but a few meant understanding the applications permitted in the enterprise. The Cisco IPJ article Boosting the SOA with XML Networking reminded me with this excellent diagram.
Those days are long gone, thanks to security monstrosities like those depicted next.
My gut tells me that when I see a bunch of terms squashed into one box, it's going to be a mess to understand, inspect, and control. I expect to hear from the development crowd that XML-fu is God's gift to the Green Earth, but it will take a miracle for me to believe that Everything-over-HTTP-over-port-80-TCP is a "good idea." We've got 65535 TCP ports to use and the whole world is collapsing onto one. Argh.
Incidentally, kudos to Cisco for publishing IPJ in such a Web-friendly format, as well as sending free printed copies.
Comments
Look at it this way though, that is 65534 less ports to worry about;-)
I refuse to wax nostalgic about the networking days of yore... if I wasn't able to spend half to two-third of any given day watching clevery disguised gorilla marketting adverts on youtube... oh, that would be a reality too terrible to imagine. =D
I think I'll stick to grand-daddies stack and let them find the real thing when they grow up.
Sometimes it's good to learn about motors a-la 1950 before being exposed to the supercharged monstors that are on todays roads
But there's a fair argument that it's us security pros that have made that the case. Since port 80 is often the only thing not firewalled, that's what get used.
Arthur
I can't remember an instance over the last year where I worked on a web service based project that ran over port 80. Its not good practice to run services off the same service you run your static content, and last I checked, most application containers were configurable to run on different ports than 80 (Tomcat, Websphere, etc), allowing for seperation of services. Running on port 80 is optional, not a requirement. And even if it wasn't, how hard would it be to set up a rule to monitor a particular context patch in a GET or POST request to determine if a call was to a static HTML page or to a web service?
In all web service implementations I've done in the last 6 months, the security folks had to have their arms twisted to do the leg work to do the necessary configuration as mentioned above. God forbid admins should take a break from their busy day of looking at videos on YouTube to do their jobs, none the less actually be able to correctly configure a router or firewall without trial and error (which happens more often than you think). This seems more of an issue of policy than a technical flaw. Smarter folks than us are backing this, so there might be something to it.
Also, why are you knocking web services for riding on HTTP's back when SSH is just as guilty, if not more so. Last I check, SSH allowed for several different encryption schemes, a telnet like session, an FTP like session, a RCP like session, X11 forwarding, and port tunneling, which, by contrast, is a whole lot more dangerous than offering a structured service to return stock quotes over a single, unencrypted port. SSH does more to throw the TCP-IP stack out the window than any other standard out there since with port forwarding, youd have to take the "nice" diagram and start looping layers 3 and 4 up through layer 7 over and over again.
Web services aren't the holy grail of programming, despite what the Java and .Net folks might like us to believe. In fact, it adds tons of unnecessary overhead. But the fact is, the tools exist for making these implementations based on them extremely easy to develop and deploy, far more so than any previous technology. While I don't believe that the future of computing is the strictly SOA that M$ seems to be forcasting and we can throw out our desktops in favor of thin web clients, it does provide a far more attractive alternative than its predecessors.
Just some food for thought.