Cosine Jeremiah and his Musings

I just found out that Paul Graham has unleashed Arc upon the world after years and years of teasing us. This is exciting, particularly for what will happen to Ruby. All of the nifty features that make Arc awesome will be extracted into a few Ruby gems in the next 2–4 weeks, and everything that Paul put into Arc will be available for Ruby.

But Cosine, you might say, Paul developed Arc so that the language would have nifty breakthrough features unlike any ever seen before to make code more concise! Without the base language support for these features, Ruby will not beat Arc at its own game!

Well, someone has already written a library (it should be reformatted properly into one, anyway) in response to the Arc Challenge that implements part of the Arc standard library, exposing for Ruby any language features in Arc that Paul was trying to showcase in the Arc Challenge.

Paul, please give us a challenge that shows a fundamental language design difference rather than displaying a gap in the presently available libraries. I know you are a smart cookie, so you must be hiding something up that sleeve.

Actually, I can think of one advantage Arc has over Ruby. Arc is Lisp whereas Ruby is not, and following from that Arc has macros while Ruby has ugly workarounds to fake macro writing. But everyone already knows that. Hmmm, maybe what we really want to do is have all our Ruby gems and Rails made available for Arc? Arc on Rails, anyone? I think that would be pleasant.

Are you stuck in a J2EE framework that leaves you feeling like this?

Ilook

Why wait? Get out there and get started with Rails today!

If you started reading this blog recently, you might wonder where I have been for the last two weeks. I apologize for my absence. I have been extremely busy working with a wonderful team on a new project. I have dedicated all of my spare time to that, so I have not had time to write articles here. However, I promise I will be back in business with new posts in another week or two! Thanks!

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.

Have you ever been jamming away on a Unix host’s command line and wish you could share your session with others? Perhaps you could do so to show someone else something you found on the system? Maybe you want that someone to type a password for you? Or perhaps you need to share the experience of going through some prompts and how to answer them? Recently there have been a myriad of technologies that can share windows and even whole desktops, but those programs are not always handy or appropriate.

Fortunately, the GNU Screen program can share that command line session of yours with other users with accounts on the same Unix host. Screen comes with a multi-user mode that allows them to connect to it. Each user can be granted permissions to each window to view, interact, or issue other commands to Screen. Here is a .screenrc file I have used to implement three groups of users: read-only users that can view all windows, read-write users that can also type in all windows, and an administrative user (the account that runs screen in my case) that retains all permissions within Screen.

multiuser on

aclchg READERS +r-wx "#"
aclchg READERS -rwx "?"
aclchg READERS +x colon,license,windows,next,prev,select,other,detach,suspend,redisplay,lastmsg,windowlist,help,stuff

aclchg WRITERS +rw-x "#"
aclchg WRITERS -rwx "?"
aclchg WRITERS +x colon,license,windows,next,prev,select,other,detach,suspend,redisplay,lastmsg,windowlist,help,stuff

aclgrp watcher1 READERS
aclgrp watcher2 READERS
aclgrp trusted1 WRITERS
aclgrp trusted2 WRITERS

aclumask "*"-rwx cosine+rwx READERS+r-wx WRITERS+rw-x "?"-rwx "??"-rwx

In this example, the administrative user is cosine. The read-only users watcher1 and watcher2 are in the READERS group. Likewise, the read-write users trusted1 and trusted2 are in the WRITERS group. Users are placed in groups with the aclgrp command.

The other commands to set this up can be understood with a careful read of Screen’s man page. The short of it is that for READERS we give read access but no write or execute (+r-wx) for all windows (#), then we do not allow any access (-rwx) to any Screen commands. Next we do enable access (+x) to a reasonable set of Screen commands necessary for navigation and comfortable viewing—otherwise Screen would not allow the user to change windows, exit his session, or a few other commands Screen users take for granted. The aclumask command provides a similar level of coverage to windows that are yet to be created. The WRITERS group is given similar permissions, except users in that group are also allowed to write (i.e. type things) into all windows.

If we wanted to create an ADMINS group that had full control of screen (able to create new windows and execute arbitrary screen commands), we could do so by replacing the aclumask command with another that replaces the mention of the cosine user with an ADMINS group, adding a pair of aclchg commands to grant this group access to everything, and then adding some users to the group:

aclchg ADMINS +rwx "#"
aclchg ADMINS +rwx "?"

aclgrp cosine ADMINS
aclgrp admin1 ADMINS
aclgrp admin2 ADMINS

aclumask "*"-rwx ADMINS+rwx READERS+r-wx WRITERS+rw-x "?"-rwx "??"-rwx

If you begin experimenting with these “acl” commands in Screen, do make sure you test your configurations before using them. Screen did not make these commands particularly user-friendly, and they do not always behave how you might think they do. They feel like they were bolted onto the program as an afterthought, and if you have been reading my blog for very long you know how I feel about that. I would not use Screen’s multi-user mode for any high-security application.