Z39.50 and SSL

Dear all,

Securing Z39.50 was discussed at the Belgium ZIG, and the consensus was that
security should be at a different layer to Z39.50 rather than built into the
standard. The main contender for this was to send Z39.50 messages (or PDUs)
over SSL (Secure Sockets Layer). This should be possible by modifying
existing toolkits to replace the sockets transport library they currently
use to a secure sockets enable library. The additional work to do this was
agreed to be fairly minor (requiring a few modifications to the code and a
recompile etc.).

At that point secure and insecure Z39.50 could be modelled on that for http
(and https). The client would need some hint whether to use secure or
insecure connections (in web browsers this is the function of a https URL
rather than a http URL - in Z39.50 this would be a checkbox or additional
flag when defining the target - e.g the user would need to specify the
targets IP address, IP port,  ... and whether to use SLL - or find this e.g.
by a directory service). A server needing to support both secure and
insecure Z39.50 would run the two servers on different ports (standard of
210 for insecure Z39.50 and a new number to be registered for server Z39.50)
as again is the case with http and https etc.

However, I did indicate at the time that I thought Z39.50 could be tunnelled
over SSL without rewriting any toolkits or existing clients or servers. I
have now located some code which would allow just that - STunnel available
from http://www.stunnel.org (available with source under the GNU public
license).

This acts as a TCP/IP proxy which does SSL encryption/decyption. On a server
you would run this on a new port. Incoming secured traffic (in our case
Z39.50) would be received by this proxy, decrypted and passed in its
unencrypted form to a server running on another port on the same machine.
Hence STunnel places on an existing Z39.50 server would enable SSLed Z39.50
(and suitable edits to ip wrappers could prevent external access to the
insecured Z39.50 server if you needed to enforce encryption). In many cases,
this is probably as good as having a Z39.50 server with inbuilt SSL support.

STunnel can also be used in a client mode to enable SSLed Z39.50 clients. In
this case the standard client is configured to connect an STunnel server
running on the same machine as the client. This takes the tcp.ip/Z39.50
traffic encrypts it and passes it onto the secure Z39.50 server (specified
when you start the STunnel software on the client). Clearly this is more
cumbersome since you have to manage starting and stopping the STunnel
software to talk to different Z39.50 targets etc. and so unlike STunnel on
servers would probably be more of an interim solution or for use in
testing/evaluation rather than an alternative to building SSL support into
clients.

Matthew Dovey
R&D Manager
Oxford University Libraries Automation Service

Received on Monday, 14 August 2000 09:13:48 UTC