HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

JMS-based enterprise messaging has emerged as the ideal backbone for mission-critical and business-sensitive data across the extended enterprise.

As the need for more robust security measures arises, SSL is frequently used to secure messaging communications. But is this using a sledgehammer to crack a nut? System architects have choices when considering techniques that strike the right balance between performance and security. One of the main concerns of any middleware security solution is encryption. This article discusses different encryption technologies that are used to secure JMS and how to find the best compromise between your security and performance demands.

Introduction
The Java Message Service (JMS) has been enormously successful as a messaging technology - well beyond the expectations of its original devisors. Today, if you make a telephone call, conduct a banking transaction, purchase goods from a supermarket, or trade in shares, there's a good chance that JMS has been involved somewhere in the process. For most of these applications, security is a key consideration. Although the JMS specification writers chose to remain silent on the topic of security, the vendors have found it to be a fertile ground for innovation and for differentiating themselves.

As JMS is increasingly employed to exchange mission-critical and business-sensitive data between business partners, security is a paramount concern when extending business communication across the Internet, which is viewed as a hostile environment.

There are three linchpins in any middleware security solution: authentication, authorization, and encryption.

Authentication
Authentication is the process by which the identity of a principal (i.e., user) is established. Most commonly this is accomplished through a user name and password, but it could be via a digital certification or more esoteric mechanisms such as thumbprints or an iris scan. Java Authentication and Authorization Service (JAAS) has provided a standard mechanism to allow pluggable authentication, allowing organizations to select their authentication method and technology of choice.

Authorization
Authorization is about granting or denying rights to principals. Typically, JMS destinations are organized into hierarchies and principals into groups. Groups are then granted or denied rights to some part of a destination hierarchy, such as send, receive, or administer.

Encryption
The final member of the security triumvirate is encryption. As illustrated in the opening paragraph, JMS is frequently used as a conduit of mission-critical and business-sensitive data. In such scenarios it's vital that the transported data is not revealed to unauthorized third parties. Encryption is used in JMS to secure the content of messages.

A More Efficient Sledgehammer - Making SSL Go Faster
In the minds of many architects and developers, middleware encryption and SSL are synonymous. Later in the article I'll argue for other approaches, but first let's explore SSL. Secure Sockets Layer (SSL) was first defined in late 1996 by Netscape; its principal goal was to secure the communication between a Web browser and a server. However, it has since broadened out to become the de facto means of securing client/server communications.

The original Internet Draft entitled "The SSL Protocol Version 3.0" specifies:

A security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

It has since spawned an Internet Engineering Task Force (IETF) working group to create a de jure standard Transport Layer Security, or TLS. Many middleware products now support SSL 3.0 and TLS 1.0. Support for SSL 2.0 is now rare due to its well-known security flaws. The TLS now maintains the definition of the elements of transport layer security including HTTPS and variations in ciphersuites.

SSL has three basic properties:
1.   The connection is private: Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption as this is dramatically cheaper to compute than the public-key asymmetric alternative.
2.   Identity can be authenticated by asymmetric or public key cryptography: This is typically done using a digital certificate.
3.   The connection is reliable: Message transport includes a message integrity check using a keyed message authentication code (MAC). This authentication code acts as a digest of the SSL data and confirms that the data has not been modified in transit.

Inside the Sledgehammer
Handshake

One of the reasons that SSL is so expensive is the cost of establishing a connection. In situations where your applications establish a small number of long-lasting connections, this may be irrelevant. However, the impact will be significant where your messaging requires many ephemeral connections. The SSL connection process works like this (see Figure 1):
a.   The JMS client sends the broker the ciphersuite that it is able to support and a random number that's used to start the key-generation algorithm.
b.   The broker will compare the JMS client's ciphersuite with its own and select one cipher that will be used for the connection. It also generates another random number as stage two of the key generation algorithm. The broker then sends to the client its certificate, a random number, and the chosen cipher.
c.   The JMS client checks the broker's certificate against its CA certificate and extracts the public key. It generates a random string called the pre_master_secret and encrypts it using the broker's public key and transmits it to the broker.
d.   Both the client and the server compute the secret keys required for the encryption and message digest algorithms. The inputs to this algorithm are the pre_master_secret and the two random numbers generated by the broker and client.
e.   The JMS client sends a digest of all the handshake messages to the broker.
f.   The broker sends a digest of all the handshake messages to the JMS client.

Figure 1

For some of you this is more detail about the SSL connection mechanism than you ever wanted to know! The real takeaway message from all this is that establishing SSL connections is expensive. It involves five messages between the client and broker and two very costly asymmetric cryptographic operations. In fact, this whole operation is so costly that hardware accelerator companies have built a healthy business just boosting the connection time for Web sites.

There are two routes open for reducing this cost:
1.   Fewer connections: Designing your JMS applications so that you open connections less frequently is obviously desirable. One design pattern for achieving this is the use of connection pooling in which connections are recycled for other users rather than closing and opening a fresh connection.
2.   Message-level security: One route for overcoming the connection cost is to use message-level security over a regular TCP connection. This is described later in the article.

Cipher
The choice of cipher can have a large impact on messaging performance. It's not uncommon for JMS users to ignore the ciphersuite parameter on their JMS product, leaving the message broker to select which cipher to use. Typically the broker will choose the strongest cipher available to it, which is often triple DES (3DES). This will seriously impact performance and may be considerably stronger security than the user had ever intended.

Figure 2 shows the message rate aggregated across all the subscribers when both the publishers and subscribers are using SSL. This shows that triple DES is consistently double the cost of using 56-bit DES.

Figure 2

Although DES and 3DES are commonly used, they rarely make the best choice in a cipher. If performance is a concern, an RC4-based cipher is a considerably better choice. If cipher strength is of paramount importance, then a 128- or 256-bit AES is a better choice when it's supported by the JMS vendor. AES is the new NIST standard for encryption and is designed to replace DES. This block cipher algorithm is faster and more secure than DES and therefore makes an excellent choice.

Native Code Implementations
Almost all JMS implementations use a central broker, which runs on a JVM. The use of Java brings many benefits, and JIT (Just in Time) compilers have made the performance penalty almost negligible in many situations. However, encryption/decryption operations are very computationally expensive and will tax even the most efficient JVM. One route to claw back some of this SSL-induced performance degradation is to use an SSL implementation that provides a native code encryption/decryption option. Typically this uses a C cryptography library that is integrated via JNI with the JVM to carry out the crypto operations.

A More Efficient Nutcracker
As the title of this article suggests, SSL is a very heavyweight solution to what in many situations is a relatively simple problem. SSL includes an expensive connection handshake, the use of digital certificates, and subsequent encryption and digesting of the entire traffic between the JMS client and broker. This traffic will contain much more than just the message contents as well as:

  1. The JMS message header fields
  2. The JMS message properties
  3. The protocol wrappers around the JMS messages
  4. Additional client/broker communications such as acknowledgments
If your only concern is to ensure that your business-critical data in the message body is secured, encrypting and digesting the rest of the protocol data is wasteful. An alternative approach is to focus your precious CPU cycles on encrypting and/or digesting the message bodies.

Figure 3 shows the effects of moving to a message-level encryption and digesting scheme. Typically this is switched on and off by administrators at a JMS destination level and is transparent to the application developer. This allows applications to be written in a JMS vendor-neutral manner while still enjoying the benefits of this facility.

Figure 3

As Figure 3 shows, the performance of message-level encryption is close to SSL for small numbers of subscribers. However, as the number of subscribers increases, the performance benefit of message-level encryption becomes rapidly significant and compelling. This is due to the fact that SSL has no understanding of the data it's transporting and will encrypt its traffic separately for each of the subscribers, i.e., for n subscribers we will see n encryption operations on the broker and n decryption operations across all the clients. Message-level encryption requires only a single encryption on the broker and n decryptions across the clients. Where the clients are distributed to different machines, the difference between SSL and message-level encryption can be very marked - SSL systems are frequently CPU bound.

Per-Message Encryption
The final twist on the message encryption theme is the ability to control encryption on a per-message basis. Imagine a scenario in which a JMS destination is being used for communication between a supplier and all of his or her customers. The supplier may send out frequent updates to pricing in an attempt to attract buyers. Should one of the customers be tempted by the discounts, the supplier will respond with an order to the same JMS destination. As the pricing data is not sensitive, the system architect does not want to pay the performance penalty imposed by encryption. However, the order has business-sensitive data, including credit card details, and should be protected from both prying eyes and modification en route.

The solution to these issues is the use of a message-level encryption where encryption and digesting can be turned on and off by the sending application. This is typically achieved using a message property that's predefined by the particular JMS implementation for this purpose.

Summary
The gratuitous use of SSL can be bad for your messaging health! If you can't get the messaging rate you need using SSL, it has traditionally meant adding more CPUs and message brokers to your architecture. However, message-level encryption and digesting can claw back performance and bring your project back on budget. While security can be a tough nut to crack (and should be!), it's important to choose your message-encryption techniques carefully to ensure the best balance between security and performance, and avoid CPU-intensive overkill.

Resources

  • Monson-Haefel, R., and Chappell, D. (2000). Java Message Service. O'Reilly & Associates.
  • Rescorla, E. (2001). SSL and TLS: Designing and Building Secure Systems. Addison Wesley.
  • Sun's JMS specification: http://java.sun.com/products/jms/
  • The SSL Protocol v3: www.netscape.com/eng/ssl3/draft302.txt

    Author Bio
    Steve Trythall is director of product management at Sonic Software. He has over two decades of experience as a software engineer, chief architect, and product manager building products as diverse as operating systems, compilers, middleware, and MOM-based applications for oil and gas exploration. [email protected]

    All Rights Reserved
    Copyright ©  2004 SYS-CON Media, Inc.
      E-mail: [email protected]

    Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.