|
|
               
|
By Mark Gibbs Start-up Digitivity, Inc. has developed a unique product that sweeps away Java security concerns. After testing the product, called Cage, I've concluded that intranet managers grappling with Java applets will put Digitivity's offering into that rare can't-live-without category. That's because Cage will allow them to quarantine Java applets so they can't enter an intranet. Cage provides a couple of additional benefits, too. It lets clients with low-power processors share a centralized, high-performance server for applet processing, and it seems to run applets more smoothly and faster than Java browsers do. Knowing Java appletsCage's usefulness is due to the limitations of the Java security model. An explanation of how Java applets are architected will foster an understanding of how security in the Cage environment works.Creating an applet involves compiling Java source code into Java byte code, which can't execute on a processor because it isn't machine code. Java byte code requires that a run-time system, called a Java virtual machine (JVM), be executed. When an applet is to be run, the Cage Server's JVM reads the byte code, validates it and then can interpret it directly or, in its next release, hand it to a just-in-time (JIT) compiler. The compiler will convert the byte code into machine code for execution, allowing for much better performance than if the byte code is interpreted by the JVM. Because byte code is a much higher level language than machine code, it is possible to verify what the program is going to do. Illegal operations can be detected before execution, and the applet can be prevented from running. But over and above this validation is the fact that Sun Microsystems, Inc. based its Java security model on a number of built-in limitations of the JVM. While these limitations significantly constrain what applets can do, they don't make it impossible for applets to perform hostile actions. For example, an applet could run in such a way as to reduce system performance simply by executing a tight loop in the code or hogging a resource such as the sound subsystem. The result in both cases counts as a denial-of-service or nuisance attack. In many JVM implementations, breaking such a loop requires rebooting the computer. While banning Java applets certainly addresses the security problem, it is hardly practical. So many commercial sites now make extensive use of applets, and so many useful applets are available that an alternative is required. Digitivity's approach is the only one I've found that addresses the broad range of security concerns while still allowing Java applets to function normally. Cage isolates client systems from Java applet code by running applets on a distinct machine - in other words, it removes direct client access to the applet. With Cage, a specialized proxy server, called AppRouter, handles all HTTP and File Transfer Protocol requests. For this to happen, all browsers on the intranet have to be configured to use the AppRouter as a proxy. Typically, this modification can be done through the automatic browser proxy configuration in Netscape Communications Corp. and Microsoft Corp. browsers. When a browser makes a request, the AppRouter passes it to the target server, which, incidentally, might be another proxy server as part of a firewall. When it receives the response, the AppRouter examines the datastream looking for the HTML tags specifying that an applet is to be run. At this point, the AppRouter replaces the applet description with a specification for Digitivity's ProxyApplet, which is downloaded from the Cage Server. When the ProxyApplet loads in the client, it sends the target applet URL to the Cage Server using a Digitivity protocol called dctp. In turn, the Cage Server loads the target applet, executes it using its JVM and, via dctp, sends the target applet's I/O requests to the ProxyApplet. Everything Java applets do in opening and closing windows, creating the user interface, making socket connections and computing is through a JVM. Digitivity's JVM is specially written so all applet code execution occurs on the Cage Server while all I/O operations are redirected to a remote ProxyApplet. The remote ProxyApplet does nothing more than output display and capture user input. Dctp, a data-only protocol, doesn't do anything other than transport data between the target applet and the ProxyApplet. Because no code is transferred and no processing is done at the client, the integrity of the client environment is maintained, even if a rogue applet causes the Cage Server to lock up or crash. Building the CageWhile installing Cage is a breeze, eating up only about 15 minutes, you'll want to carefully plan the interaction of the Cage system with firewalls and proxy servers so you get the best possible security level. This requires an understanding of the protocols and connections involved. In its documentation, Digitivity does a good job explaining architectural considerations and providing extensive explanations, worksheets and checklists to help you through the design process.The Cage Server installs as an NT system service. Unlike many other products I've tested, I didn't even have to restart the system after installation. In fact, the Cage system starts the service and enables it to be automatically run at start-up. Once running, the only user interface to the Cage Server is through the NT Task Manager. AppRouter has a user interface for configuration and monitoring. In addition, it offers lots of reports that you can use to track what is being asked for and what response is made. In Cage, Digitivity has definitely combined a great idea with an impressive implementation. Cage is one of the coolest products I've seen this year.
How to Advertise | Copyright
Home |
NetFlash |
This Week |
Industry/Stocks
|
