11.5. Does this really work?

After all the work we've gone through to setup security, you might be a bit disappointed. After all, we've gone through all the trouble of setting up a CA and some certificates to end up writing a MathService client that behaves just like all the other MathService clients we've already seen in the tutorial. Ho hum. You're probably asking yourself: "Yeah, but is this really doing all that encryption thingy?"

To empirically prove that it is doing the 'encryption thingy', we are going to use an Apache Axis tool called TCPMonitor that is included with the toolkit. This tool allows us to intercept the data that is sent from the client to the server (and vice versa). We will see how the information is, in fact, encrypted.

To start TCPMonitor, run this:

java org.apache.axis.utils.tcpmon 8081 localhost 8080

This starts an instance of the TCPMonitor (Figure 11.1, “TCPMonitor interface (1)”). What the monitor will do is listen on port 8081 and redirect all the traffic it receives on that port to port 8080 (which is where our container is listening). This means that TCPMonitor acts like a proxy, not like a sniffer, so we'll have to tell our client to make the invocation on port 8081 to be able to see what kind of data is being sent.

Figure 11.1. TCPMonitor interface (1)

TCPMonitor interface (1)

Make sure you check the "XML Format" box in TCPMonitor. This will make reading the messages much easier.

Let's run the client again. Make sure to change '8080' for '8081' so that the invocation will go through the TCPMonitor. Otherwise, we won't be able to see it.

java \
-classpath ./build/stubs/classes/:$CLASSPATH \
org.globus.examples.clients.MathService_instance_4op.Client_GSISecConv_Encrypt \

Once you've invoked the service, the TCPMonitor will reflect that it has intercepted some connections on port 8081 (Figure 11.2, “TCPMonitor interface (2)”). The top list shows a list of the connections. You can select any of them to see what was sent to the server (top text area) and what the server replied to the client (bottom text area).

Figure 11.2. TCPMonitor interface (2)

TCPMonitor interface (2)
[Tip]Five calls and eight connections... huh?

TCPMonitor should show 8 connections. This might seem a bit odd considering that our client only makes five calls to MathService (add, subtract, multiply, divide, and getResourceProperty). However, remember that we're using GSI Secure Conversation.

As described in the previous chapter, GSI Secure Conversation involves the creation of a security context before the client and server can actually communicate. This accounts for the first three connections. The client and server are agreeing on the details of the secure context. Once the context is created, the calls can proceed as normal.

Let's take a look at the fourth connection, corresponding to the add invocation:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
         <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2004/04/sc" 
            <xenc:DataReference URI="#EncDataId-749304"></xenc:DataReference>
      <wsa:MessageID soapenv:mustUnderstand="0">uuid:837bf290-b079-11d9-a882-a1d8507fabe7</wsa:MessageID>
      <wsa:To soapenv:mustUnderstand="0">
      <wsa:Action soapenv:mustUnderstand="0">
      <wsa:From soapenv:mustUnderstand="0">
      <xenc:EncryptedData Id="EncDataId-749304" Type="http://www.w3.org/2001/04/xmlenc#Content">
         <xenc:EncryptionMethod Algorithm="http://www.globus.org/2002/04/xmlenc#gssapi-enc"></xenc:EncryptionMethod>
         <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               <wsse:Reference URI="#SecurityContextToken-15021407"></wsse:Reference>

Holy gibberish, Batman! :-)

Notice how only certain parts of the message are encrypted, not the whole message. Remember that this is because GSI Secure Conversation is a form of message-level security (explained in Section 10.2, “Transport-level and message-level security”). This means that we only encrypt the contents of the message, but not the whole message. Notice how the message still reveals what the service URI is, along with the operation name, but the actual call itself is encrypted. If we wanted the whole message to be encrypted we would need to use transport-level security (GSI Transport).