Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Secure your Java apps from end to end, Part 3

Build better networked applications

By Todd Sundsted, JavaWorld.com, 08/10/01

In this series, I have encouraged you to look at security from three different directions. In the first two articles, I focused on virtual machine security and application security. This month, I will discuss the final security context -- network security.

• Part 1: The foundation of Java security: Virtual machine and byte code security
• Part 2: Don't let flaws compromise application security
• Part 3: Build better networked applications

Network security deals with securing the communication channel between two entities so they can communicate -- each entity confident in the other's identity and in the integrity of the messages exchanged over the channel.

A number of reasons make building secure networked applications a challenge. The difficult subjects upon which modern security is built (such as cryptography) can sometimes confuse developers. Also puzzling are the opaque presentations of key standards and technologies -- such as the X.509 certificate standards. However, at the end of the day, network security is difficult because the characteristics of the network medium itself prove hard to understand. The following analogy illustrates why:

When we converse in everyday life, information about the party with whom we communicate comes through multiple mediums, such as sight and sound. We use this information to authenticate the other party's identity and to judge the channel's quality. Even when we converse over the phone, we can adeptly judge the identity of the party on the other end from nuances in tone, speed, and inflection, not to mention the conversation's context.

Communication over a medium such as the Internet provides far fewer clues. Imagine speaking with a friend in another room through a tin can telephone. Its poor signal quality obliterates many of the audible clues we use to identify each other. The tin can scenario resembles the situation that most applications experience on the Internet or other networks.

Security in the network context consists of authenticating the other entity over this anonymizing channel, and protecting the communicated information from eavesdropping and accidental or malicious modification.

I have written extensively about the tools and technologies used to secure communication at the network level (see Resources). I focus this article on practical guidelines to follow and issues to consider when designing and implementing a network security solution.

Understand what you want to protect

Designing a security solution begins with the information you need to protect. Moving financial transactions across the Internet requires much stronger security than downloading a Webpage full of last week's sports scores. When selecting the technology and creating a design, you should consider the following design issues:

• Security adds complexity to a product's design and implementation, its installation and configuration, and often to the user interface. While security is usually a desirable feature, complexity is not. How much complexity are you willing to introduce in the name of security?
• Security, particularly the encryption and decryption operations, is often a CPU-intensive process. Most desktop and server systems have more than enough horsepower to outrun the network, but resource-constrained devices such as cell phones and PDAs often lack that strength. Can your target platform handle the load?
• Likewise, security increases application size. While not as critical in desktop and server settings, size remains a real concern in embedded applications, especially those built for the platforms the Java 2 Platform, Micro Edition (J2ME) targets. Once again, can your target platform handle the load?
  
  

  As an excellent case in point, the first version of the Mobile Information Device Profile lacked SSL (secure socket layer) support -- an essential component of an end-to-end Web security solution -- primarily because of the perception that SSL proves too heavy for mobile devices. In response to this concern, Vipul Gupta of Sun Microsystems Laboratories built a standards-compliant SSL implementation for J2ME. His work demonstrates that small devices can achieve acceptable SSL performance. Gupta's implementation achieves that goal because it supports only a reduced set of the most popular cipher suites, lacks support for client authentication by the server (an operation with a costly client-side component), and reuses expensive RSA (Rivest-Shamir-Adleman) computations across multiple connections to the same server. See Resources for more information.

Use the right technology

It almost goes without saying that selecting the right technology is important when implementing a network security solution. The choice affects the longevity and quality of the security offered as well as an application's ability to integrate into an existing security infrastructure. The JDK provides a broad range of security APIs. The following list will help you identify and select the right technology for your problem:

• Authentication and digital signatures: Java Cryptography Architecture (java.security)
• Encryption/decryption and message authentication codes: Java Cryptography Extension (javax.crypto)
• X.509 certificates: Java Cryptography Architecture (java.security.cert)
• SSL support, HTTPS URL support: Java Secure Socket Extension (javax.net.ssl)
• Pluggable authentication and authorization: Java Authentication and Authorization Service (javax.security.auth)

The JDK 1.4 beta includes:

• Kerberos: GSS (Generic Security Service) API (org.ietf.jgss)
• Certificate path validation: Certificate Path Validation API (java.security.cert)

These standard APIs will handle many of your security-related Web application and enterprise integration tasks.

Understand the network

It is not wise to design a network security solution without considering the network. The systems on which an application runs and the network over which it communicates all place their mark on a design.

Consider this edge case: You build an application that runs completely within a secure network. If the network proves secure -- and this means the network is physically protected, and the users are trusted and only carefully granted access -- then you have little need to secure the application itself. In many cases the network is not as secure as believed, and developers fail to secure the application because leaving security mechanisms out is easier than building them. However, some situations justify this approach. For example, in a clustered environment with multiple instances of an application running and communicating to balance load, it's often sufficient to secure the cluster as a whole, not the application.

On a more realistic level, securing an application typically means assessing the security provided by the machines on which the application will run (and taking corrective measures if necessary), the environment in which the machines are installed, and the network, including its access points.

Identifying the access points is important for a number of reasons. In addition to providing a portal for active attacks against the application, access points provide a window for passive sniffer activity (a "sniffer" is a piece of software that listens to all the network traffic passing by a computer -- even traffic destined for another computer). Information gleaned via the sniffer might provide access to the application, or the availability of the information might be damaging in itself (consider credit card numbers).

Understand the users and abusers

Remember that security solutions are built around people, thus you must understand the capabilities and skills of the application's users and abusers. The abusers, who are often more technically skilled than the users, further complicate the task.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.