Cosine Jeremiah and his Musings

I have had some thoughts recently about the security of SOA (Service Oriented Architecture). When using SOA, the services are often made available using SOAP (Simple Object Access Protocol) messages communicated using HTTP. Naturally, it is important to keep data secure as it is transmitted from requester to servicer and vice versa. Should one use SSL to secure SOAP? Or should we recommend WS-Security, a standard means of transforming a SOAP message to add confidentiality and integrity to the message, instead—if we limit it to one or the other, that is. Let us do a quick comparison of each solution:

1. SSL is ubiquitous and most everyone knows how to use it, whereas WS-Security is largely an “unknown” to most organizations.

2. Both SSL and WS-Security are easy to “drop in” to a typical web service architecture, though SSL is somewhat easier due to the previous observation.

Both SSL and WS-Security have programs or libraries that make adding them to an existing web service a reasonable task.

Adding SSL to a web service can be as easy as putting Stunnel or other SSL termination software in front of the service. However, to integrate SSL’s authentication features one would need to have the results of the SSL handshake passed into the application somehow. More often a server ends up using weaker credentials, such as username and password, inside the SSL connection to establish the identity of its users.

With WS-Security, implementation can be done by adding a few calls to an appropriate WS-Security library, such as WSS4J (Java) or WSS4R (Ruby).

3. SSL provides security for an entire connection; WS-Security secures each message one by one.

If an application keeps a connection open to make multiple requests of a web service, then SSL would provide better performance than WS-Security. Exactly how much better may depend on your servers’ average load. The difference in computation is due to SSL using mostly symmetric key encryption after the initial handshake at the start of the connection, whereas WS-Security needs to perform asymmetric key encryption on each message (one computation for handling encryption and one computation for handling the signature). Symmetric key encryption is a lot faster than asymmetric key encryption, and while both technologies switch to using symmetric key encryption as fast as possible to provide the best performance, WS-Security is unable to avoid those asymmetric key computations on every message.

On the other hand, since security is applied on a message-by-message basis with WS-Security, an application is not susceptible to possible channel hijacking or HTTP splitting attacks that could occur with SSL. If either of these things were to happen when WS-Security was in use then its security features would still protect the message and the data.

4. SSL requires an immediate communication with the endpoint to securely transmit data; WS-Security can protect a message that is queued up or stored on intermediate servers without additional concerns.

With SSL, the SOAP messages themselves remain unencrypted but are transmitted through a secure tunnel (the SSL link). If that message ends up being stored on a disk (queued) prior to use, then it is unprotected from being read or tampered with by anyone who can obtain access to that disk. If you think this is unlikely then you should know that attackers are often able to leverage poorly configured web, FTP, Citrix, remote desktop, and Windows file sharing servers to access disk. This is one of several reasons that encryption of data at rest has become more important recently, and “at rest” refers to any time data hits a disk or a tape, not just when it resides within a database.

On the other hand, WS-Security imposes its protections upon the message itself, so if the message were to be copied by an adversary he could not read it. If the attacker could find a way to get write access to the disk containing the WS-Security protected message waiting in queue, any attempt to tamper with the message is detected by WS-Security’s integrity protection features.

Comparison Summary

SSL (pros):

1. SSL is ubiquitous—it is easy to find people with experience using it.
2. Easy to “drop in” to a typical web service architecture.
3. Provides encryption for an entire connection.
4. Client may authenticate the server during SSL handshake.
5. Server may authenticate the client during SSL handshake.

SSL (cons):

1. Connections must be active to transport data and responses. In other words, the endpoints must have a direct channel to each other.
2. Once authenticated with the SSL handshake, any data transported on the connection is trusted. This might leave a channel open that can be hijacked and used in similar fashion to a cross-site request forgery attack.
3. Data is vulnerable to capture and tampering if left unencrypted on a disk by queuing software; extra precautions may be necessary to protect it.

WS-Security (pros):

1. Easy to “drop in” to a typical web service architecture.
2. Provides encryption for a single message.
3. Client may be assured the server is the message recipient by virtue of the public key used to encrypt the message. Likewise, the server is assured that the client is the recipient of the reply by virtue of the public key used to encrypt the reply.
4. Server may be assured the client is the message sender by virtue of the public key used to decrypt the message signature. Likewise, the client is assured that the server is the sender of the reply by virtue of the public key used to decrypt the reply signature.
5. Messages may be time limited to prevent expired messages from being processed.
6. Messages are innately protected if left on disk and queued during transmission to the consumer.

WS-Security (cons):

1. WS-Security is not ubiquitous. You will likely need to train your development staff how to use it.
2. Each individual message and its response requires processor expensive asymmetric key encryption to occur even if a communications channel is maintained. This is negligible on small loads, but systems with hundreds, thousands, or yet more messages per second may become loaded.

After reviewing the differences I suggest that WS-Security should be the preferred choice of most enterprises. Do note that I suggest you do both SSL and WS-Security (for defense in depth and to provide some security by obscurity against those that would sniff your packets), but if you were to limit it to one or the other then I would prefer WS-Security. The issue that convinced me was the security of messages left in queue on disks. This situation happens rather frequently (swap files, anyone?) and is often done unbeknown to the original application architect as the system grows and the message delivery mechanism is changed. WS-Security simply provides security from end to end without worrying that every step of the way is secured appropriately as well; SSL only promises security between the endpoints of the SSL tunnel.