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 a handy-dandy command-line tool included with Axis called TCPMonitor. 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. 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.

The TCPMonitor interface should look something like this:

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/classes/:$CLASSPATH \
org/globus/progtutorial/clients/MathService/ClientGSIConvEncrypt \
http://127.0.0.1:8081/ogsa/services/progtutorial/security/first/MathService \
5

Once you've invoked the service, you should see the following in the TCPMonitor:

The top list shows all the connections 'intercepted' by the TCPMonitor. You can select any of them to see what was sent to the server (first text area) and what the server replied to the client (second text area). There should be three pairs of connections (on pair for each of the invocations the client makes: add, subtract, and getValue.

Let's take a look at one of them:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
  <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"
    soapenv:actor="" soapenv:mustUnderstand="0">
    <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <xenc:DataReference URI="EncryptedBody"></xenc:DataReference>
    </xenc:ReferenceList>
  </wsse:Security>
</soapenv:Header>
<soapenv:Body>
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
  Id="EncryptedBody" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <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#">
      <ds:KeyName>00000000-0141-fab6-00000000-00000112d7ae</ds:KeyName>
    </ds:KeyInfo>
    <xenc:CipherData>
    <xenc:CipherValue>
    
    FwMAARBYgJbPOGPUfDe/rRt0Xig5Nvaf5xCUmLHMCUW3+kMsxgfA10ft319im/mn3PJGlLYoRo8M
    FfYMAgctOFjCPYEalpa1IhI+A28OmaVRUnCxw6QeynuQ6Op77D2p4frGd14tq0hB621JUcl3gY0F
    S4QuSZ/D5yjG+rO9mZUwL+5Y6K3umr1y8h65Cn4IQYd4uBuFYasaTOCX66PIhq+MkcfTimbHWkjG
    9o1cWcZJCgTiby4fhUsFjjzkTOFPHdY6lMMjC0qo4a5OJTq0ifjQfahjzCwfV/vsyMP7a21eAbZN
    G4ZHL0MCoIWQcZgRjFnSI28z3ZnjWTavqt3ByEbJDxGW+DnOVTikuVevLQdtZy86OA==
    </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>

Holy gibberish, Batman! :-)

Notice how only certain parts of the message are encrypted, not the whole message. This is because GSI uses message-level security. This means that the message's format (SOAP) is not encrypted, but the contents of the message are (highlighted in bold). If we wanted the whole thing encrypted (both the message format and the message's content) we would need to use transport-level security. This type of security was supported by GSI in the past, but is now deprecated.