Network Security Illustrated buy the book at Amazon now!

search site
Table of Contents














Page Tools
print this pagePrint this Page
Chapter List
Client-Server Architecture
Internet Services
Remote Access
File Transfer (web bonus)
Streaming Services (web bonus)
Peer-to-Peer Networking
Middleware/Application Services (web bonus)
More Information
Resources (links)
Sample Pages
Buy The Book
is any technology that allows two different programs to intercommunicate.

Technology Overview

In order to understand middleware security, you need to understand what middleware is, and why it exists. Middleware is a highly profitable market for software vendors, and as such they’ve made understanding it as complicated as possible. It’s often defined using circular logic: “Middleware represents the second tier in a three-tiered software architecture model, which includes the client, the server and the stuff in the middle.” In reality, middleware is very simple, and most of the complex-sounding middleware technologies actually do the same basic things.

What People Think: Middleware is a complicated expensive thing that big networks buy.

What We Think: Middleware is everywhere, used with big and small applications. It’s a marketing term, and thus is very confusing.

The confusion comes because there are many different ways for programs to intercommunicate. As a result, many things claim to be middleware. We’re going to look at the evolution of middleware, explaining each of the key technologies along the way. We’ll try to keep the acronyms down to a minimum, but it’s REALLY difficult to do without making this section read like James Joyce.

How It Works

Decades ago, programs were primarily written in languages such as C (still used today, but only in special situations). These programs were organized into task-specific procedures. The procedures would be called sequentially to perform a complex computing task. It was considered good programming practice if your procedures were reusable in other situations. Collections of reusable procedures were grouped into libraries. Programs could access these procedures by using the appropriate library collection.

As programming techniques evolved, reusing a procedure wasn’t good enough. Sometimes what you really wanted was to use a large chunk of another program’s functionality. For example, let’s say you’re developing a custom financial analysis system. You want to access real-time stock market data, but you don’t want to write all the code necessary to interact with the market feed. There’s another program that already talks to the feed and gets all the data you want. Instead of re-writing this program, you want to run it in parallel with your program. Your program should be able to ask it for information, but you don’t want to write an entire client/server communication infrastructure (protocols, remote access code, etc.).

The solution is called a remote procedure call, which is a system that allows one program to directly use another program’s procedures. This means your program could call the procedures from the market feed program directly, as if the two programs were actually one and the same. The two programs interface with each other by using a set of pre-defined procedures called … “interfaces” (shocked ya with that one, right?). The interaction between the two programs is controlled by a third program that acts as a middleman during the transaction. The software systems that filled this role came to be known as… tada!… middleware. They’re also called Application Servers.

The first system for providing this type of interoperability was creatively titled “Remote Procedure Call”, or RPC. It’s rather complicated, but is still used by some older applications, such as NFS and SMB. The biggest problem with RPC was that it was very operating system specific. Microsoft had one version, the Unix-world had another. It also was designed for procedural languages, which was fine until the computer programming world grew up a little more.

Most modern programming languages are Object-Oriented, which means that it the programs are organized into operational units called “objects”. Objects contain both data and program code. The data can include other objects. For example, a “car” object might contain wheel, engine, and body objects.

Objects communicate with each other through their program code. The code is organized into functional groups called methods. For example, the “wheel” object might have a bit of program code that determines the direction the wheel is pointing. This code is identified by a “method name”, such as “get_direction”. The car object can find the direction the wheels are pointing by using (calling) the wheel’s “get_direction” method.

The evolution of the Remote Procedure Call into an object oriented system resulted in three competing models. One model, the Common Object Request Broker Architecture (CORBA), was based on an open standard and maintained by a non-profit industry consortium called the Object Management Group. Another, the Distributed Component Object Model (DCOM), was a proprietary system developed by Microsoft. The third, Remote Method Invocation (RMI) was developed by Sun as part of the Java language. CORBA ultimately proved popular enough to force both Microsoft and Sun to make their systems CORBA-compatible. As a result, we’ll just talk about CORBA here, but the same concepts really apply to all three system.

CORBA allows different programs to exchange objects and data, regardless of the language in which the program was written. There are two critical components to the CORBA system. The first is the Interface Definition Language (IDL). This is a standard way to describe the objects and methods that a program wishes to make available. Each program has an associated IDL program, which is processed by the second critical CORBA component: the Object Request Broker (ORB). The ORB receives remote requests for objects. It then uses the IDL file to figure out how to pass the request to the program. Likewise, the ORB uses the IDL to formulate the result into something the requesting program can understand.

CORBA is an ideal system for distributed computing. Programs running on different machines across a network need to intercommunicate. The communcation system is easier to write and more efficient if CORBA is used. Instead of having to treat the program as a client/server system, it could pretend that it was just a standalone application. All the dirtywork gets handled by CORBA.

When developers first attempted to use CORBA over a network, they discovered a problem. There were a number of different ORB systems available, and each one had a different way of using a network to communicate. The result was that ORBs from different vendors weren’t able to intercommunicate.

The solution involved extending CORBA to include a third component: the General Inter-Orb Protocol (GIOP). This allowed ORBs to use a common set of commands when talking over a network. As the name implies, GIOP was not designed to be specific to any particular type of networking system; it’s a theoretical model. A practical, specialized version of GIOP was created for the Internet, called the Internet Inter-ORB Protocol (IIOP). This is the primary mechanism with with ORBs communicate today. All ORBs must support IIOP, but can optionally also support other GIOP implementations for system-specific needs.

All modern systems now include support for CORBA. All mainstream programming languages also support CORBA. There are a number of commercial and freely available ORBs; many server operating systems have one integrated. Frankly, CORBA works incredibly well and there’s little practical reason for any other system to exist.

Unfortunately, during the boom a few major industry leaders saw the Web as an opportunity to re-invent the ORB, so to speak. Ignoring the fact that distributed computing is really not applicable to most organizations; they whipped out the old CORBA hype and changed the name to Web Services. They also took the opportunity to create a brand-new system that does everything CORBA does, but requires all new software. It’s also so inefficient that it requires new hardware too. They called it SOAP, XML/RPC and .NET (depending on who you ask).

The pitch goes something like this: “For the first time you can finally write your programs in any language and have them communicate seamlessly over the Internet.” Then, they huddle all the CORBA users into a separate room and say, “Look, we know you guys can already do this, but our system is better.” The reason? Web Services can run over the web, which means that firewalls only need to allow web access (with CORBA you need to open up a few ports to allow ORBs to communicate via IIOP). This makes it much easier for companies to use your software, because they already allow web access and therefore won’t have to change any firewall settings. Furthermore, Web Services use XML, a text-based data format that is easy to read. This apparently makes it easier when debugging code. We’ll explain why these are the most twisted, inane concepts ever… after we’re done thrashing the all people who think these are “good features” with wet spaghetti.

Ah, much better. Let’s get right to the issues, shall we?

Security Considerations

Application Services and Web Services have been touted as the future of computing. Some marketing has gone as far as calling Web Services the “Holy Grail” of computing. When we hear “Holy Grail”, two things come to mind. The first is a rather fanciful religious justification used to gather support for a political war during the middle ages. The second is “jettez la vache”. Neither sounds like something we want our computers doing.

Visionaries see a world where applications, services and information flow organically across the network. Companies will be able to translate their business practices into network services and make these services available to others. One company can share the unused computing resources of another in times of need. That’s great, but in today’s world we can barely get regular information to flow between two computers without creating a massive security or functionality problem. We think the vision is a bit ambitious.

Myth: we’re in a service economy, so software should also be a service

Reality: Some things make more sense to own. Your toothbrush, for example. For now, software is firmly in that category. People like to have control over things that they need to get their job accomplished.

We’d love to rant about the entire concept underlying service software, and how it makes no business sense. About how it’s the sort of business model a technologist would come up with after “learning” all about business by reading the latest management fad books, from the comfort of his bedroom in the basement of his parent’s house. About how the marketing pitch sounds good, and all the surrounding concepts sound right, but business just doesn’t work that way most of the time. Yes, we have plenty to say on the topic, but we won’t, because the real world has already rejected this model repeatedly.

To be fair, there are certain applications where inter-application communication makes sense. Often these are in computing-intensive environments that can directly benefit from distributed computing technologies, such as financial, medical, engineering and mathematical studies. However, due to intellectual property value few of these organizations will “share” computing resources with others.

Trust: if it’s just data exchanged, there’s little risk of damage. But if it’s a service, you need to worry about whether the service you’re using is what you are expecting. For example, let’s say you use a special analysis module for your financial application. This module is provided as a service, because it needs to access a number of proprietary expensive databases. Instead of you purchasing the module and all the data streams (millions of dollars) you choose to rent access to the module. You plug in your inputs and get the results you need back. But how do you know that the module isn’t sending a log to your competitors? What if hackers have replaced the module with a rogue system?

As a result, you should only use systems that allow for strong authentication and integrity checking. Even if the service is provided internally, you should use authentication to make it that much more difficult for hackers to alter the code. After all, if a hacker gets your server, they can directly control much more.

Control: Firewalls and VPNs are useless with Application Services. All services come over one channel, regardless of the application. In the days of CORBA, at least it came in over a specific TCP port. This meant that you could use your firewall to only allow CORBA traffic from a specific server.

Firewalls are funny. Everyone buys one for security purposes, and then complains when they work. The point of a firewall is to selectively control the types of applications that can access a network. But many administrators don’t really understand firewalls, so they’re afraid to adjust them past the basics. Usually this means allowing web traffic to pass through. As a result, the administrator feels safer when a new application can just use the existing hole in the firewall.

Remember the wet spaghetti? The fact that Web Services work over the web means that your firewall can’t distinguish between web services and normal web traffic. Sure, it doesn’t require adjusting, but this means you lose the ability to control where your services are coming from. Any website could start controlling the machines within your network via Web Services. The only way to avoid this is to properly configure each machine within the network that can access the web. This is far more of a headache than adjusting the firewall once. Hacking via Web Services is going to become a major problem over the next few years.

There are two solutions to this problem. The first is to run a web proxy that is capable of filtering out all web service type traffic. This is probably the most effective solution. The other option is to configure each machine to ignore web services. This may range from difficult to impossible, depending on the levels of control provided by Operating Systems vendors.

Performance: There was a second reason for the spaghetti incident: the choice of XML as a transfer format. XML, as a text-based format, is very network inefficient. It requires much more bandwidth to communicate over XML versus CORBA. This means it also requires faster computers for processing the information. The HTTP protocol is also not ideal for extended two-way communication. Certain applications that require large and extensive communications will suffer dramatically as Web Services.

Visibility: The other downer to XML is that the contents of the communications are in plain text. This makes it painfully easy for a hacker to see what’s going back and forth. CORBA requests travel as binary data, which is much harder to figure out without intimate knowledge of the communicating programs. Nonetheless, this is not a strong security system either – it’s just obscurity and a determined hacker can also figure out what’s happening across CORBA.

Transparency: Beware of transparency. Application Services are complicated. There’s a big push to make the process as transparent to the user as possible. For example, a single web page might be composed of information from 20 different sources. The user just sees one page and assumes the information is controlled by a single entity. If one of those sources is corrupted, how is the user to know? This is even harder to track when the information displayed is customized to the user.

Making The Connection

Internet Services: Middleware is most often used as a bridge technology between Internet Services and serious back-end network infrastructure.

Hiding Information: Most modern middleware platforms support encryption at some fundamental level.

Best Practices

Encryption is necessary to truly secure inter-application communication. Both Web Services and CORBA support encryption. Web Services provides it through an add-on to XML called XML Encryption. CORBA handles it through the CORBA Security Service. This is a relatively recent addition to CORBA and therefore is at roughly the same maturity level as Web Services security. Nonetheless, there are many commercial and freeware ORBs that are compliant to the CORBA Security Service.

Final Thoughts

The real winners from the Application and Web Services revolution are the middleware vendors. They’ve found a way to sell the same product over and over again. Certification providers also win big, because there’s lots of new technology to learn about. Finally, large companies can force all of their suppliers and distributors onto a common platform. Maintaining a single system is much easier for the large company. The hype surrounding the new technologies makes it easier to convince the smaller distributors and suppliers to invest in the necessary infrastructure on their end. After all, this will benefit them because everybody will be using this new system and they’ll be ahead of the game, right? Yeah. In reality, the suppliers and distributors end up maintaining multiple, expensive systems.

More Information

The above information is the start of a chapter in "Network Security Illustrated," published by McGraw-Hill and available from, as well as your local bookstore. The book goes into much greater depth on this topic. To learn more about the book and what it covers, click here.

Below, you'll find links to online resources that supplement this portion of the book.


(websites, books, etc.)




Sample Pages