Exporting a private key from a Java keystore for use in Wireshark

I recently had to debug a client/server interaction that wasn't working in the way that I thought it should be. To cut a long story short there was some authentication data getting cached somewhere so that two calls to the server with the same username but different passwords were both authenticating provided the correct password was used first time round. I wasn't happy about this.

For the record the server was running within Apache Tomcat and the client was built using Apache HttpClient. The client code was mine but I didn't have direct access to the server, although I knew the guy who did.

At first I assumed the problem was of my own making, something I'd messed up or misconfigured in the client code. After all, the documentation for HttpClient does say things like this:

As of version 4.1 HttpClient automatically caches information about hosts it has successfully authenticated with. Please note that one must use the same execution context to execute logically related requests in order for cached authentication data to propagate from one request to another. Authentication data will be lost as soon as the execution context goes out of scope.

I wanted my client code to be able to reuse an instance of HttpClient for each instance of this particular server it was connecting to, so I was sharing both that and the associated HttpContext object between calls. I thought that by using a fresh HttpContext object for each call I would solve the authentication caching problem. But that didn't help. Neither did all kinds of other tweaks I made to the HttpClient and HttpContext objects - if it offered so much as a hint of a solution, I tried it.

I got to the stage where I could pretty much recite back the API documentation to anyone who would listen when I decided I would have to see what was actually going out on the wire. So I installed Wireshark.

Sniffing SSL packets with Wireshark is easy enough so long as you have the server's private key. But when Tomcat is your server the private key is in a Java keystore, and keytool can't export private keys. There is a round about way though via keytool and OpenSSL.
First create a PKCS12 keystore from your server's JKS keystore:

$ keytool -importkeystore -srckeystore server.jks -destkeystore server.p12 -deststoretype PKCS12

Then use OpenSSL to check that everything looks ok:

$ openssl pkcs12 -in server.p12 -info

You can't just copy the private key from the output of this stage as it's still encrypted and Wireshark needs a plain key. Simply adding the -nodes switch sorts this out, but we might as well use a command that does all the splitting out into a file at the same time:

$ openssl pkcs12 -in server.p12 -nodes -nocerts -out server.pkf

Now we have a private key in server.pkf that Wireshark can understand. The Wireshark documentation will show you how to use it.

Turns out the problem was with the server - not Tomcat itself, but the webapp running within it. Something deep inside was caching the authentication tokens. This has now been fixed.

Typing # in emacs on OS X with a UK keyboard

What a pain!

It's bad enough that the Apple UK keyboard doesn't have an obvious way of typing a # - alt-3 since you ask, and it's not printed on the key either like the Euro symbol, €, is! This isn't such a terrible thing in most editors since alt-3 isn't too hard to cope with. But in emacs the alt key is mapped to Meta, so alt-3, by default does something else - not sure what.

Thankfully, this is emacs so it's easy enough to put right, simply add the following to your .emacs file:

(global-set-key (kbd "M-3") "#")

Done and done.

cdecl on the web

cdecl is a really useful tool for working out what a C type declaration is in English. For example:

const char** x

is translated into

declare x as pointer to pointer to const char

That is a very simple example, but it really comes into its own when given something nasty, like this:

char (*(*x())[5])()

which is:

declare x as function returning pointer to array 5 of pointer to function returning char

And you can go the other way too:

declare x as pointer to const pointer to int

becomes:

int * const *x

Which is all rather nice.

What is really useful is that it is available online at http://www.cdecl.org.

Using macports emacs-app from the command line

Having installed emacs-app from MacPorts I wanted to be able to use it like I do emacs under Linux, i.e:

emacs file.txt &

But you can't run 'proper' OS X applications like that. There is, however, a command called open which can help. Here is how you would rewrite the Linux example above using open:

open -a emacs file.txt

The -a switch tells open which application you want to use to open file.txt and it automatically looks in the Applications folder for it. Note that you don't need the ampersand on the end of the line as OS X appears to fork the application for you.

From there it is pretty easy to set up an alias to do all that for you. Simply add the following line to your .bashrc:

alias emacs='open -a emacs'

Nice.

Emacs Splash Screen...

For a couple of years now Emacs has been starting up with a splash screen showing by default. Even if you start it from the command line and give it a filename to load.

This has never bothered me under Linux because just clicking in the window with the mouse makes the splash screen disappear and brings the file you actually asked for to the front. I've recently installed emacs-app from MacPorts on my Mac though and upon startup it actually opens the splash screen in a different window (or "frame" in emacs parlance), which I really don't like. It's much too obtrusive now.

Thankfully, emacs being emacs, you don't have to stand for this outrage! You can turn off the splash screen completely by dropping the following into your .emacs file:

;; Remove splash screen
(setq inhibit-splash-screen t)

Sorted.

The easy way to add MPEG2 encoding to VTK!

The Visualization Toolkit (VTK) can be set up at build time to provide MPEG2 encoding. This is an optional extra due to the fact that there are patents attached to MPEG2 encoding and Kitware, who develop VTK, want to be able to distribute it as both free and unencumbered software. They do provide an MPEG2 library that can be slotted in at build time but it is not immediately obvious how to do so.

I have found that the most straight forward method of building this MPEG2 library is to drop it into the VTK source directory and add it directly into the build system rather than building it separately outside of VTK. Indeed, the VTK MPEG2 distribution has all the necessary CMake hooks required to do just that.

• Once you have un-tarred the VTK source tree cd into VTK/Utilities.
• Un-tar the VTK MPEG2 library here.
• Go back to the root of the VTK source tree and load CMakeLists.txt into your favourite editor.
• Search for 'MPEG2' in the file (line 764 in version 5.2.1, line 793 in version 5.4.0) and about 30 lines below that comment out this line: INCLUDE(${VTK_CMAKE_DIR}/FindMPEG2.cmake OPTIONAL) - CMakeLists.txt uses # as a comment marker.
• In place of that line you need to add the following one: ADD_SUBDIRECTORY(${VTK_SOURCE_DIR}/Utilities/vtkmpeg2encode)

Now you can build VTK as normal, making sure that you turn on VTK_USE_MPEG2_ENCODER in the configure stage. When building VTK the MPEG2 library will be one of the first to be built.

AVS/Express on Ubuntu

Ubuntu (Dapper Drake - 6.06 and Hardy Heron - 8.04) doesn't have a modern enough version of Motif/Lesstif for AVS/Express by default. Installing the latest version of OpenMotif will do the trick, but you still need to tell Express where this self-installed OpenMotif is. This didn't bite me until I had to compile and use my own modules within Express so you may not need to do this if you're just using the standard tools.

• In the Express installation, find the file include/MACHINE/machinc.mk (where MACHINE is your architecture, eg. linux_64).
• Edit the MOTIF_HOME variable to point at your new OpenMotif installation. The, incorrect, default will be $(X11_HOME).
• Edit the XMPATH variable to point to the lib directory within your OpenMotif installation if required. This should most likely be $(MOTIF_HOME)/lib.

That's it!