- From: Matthew Dovey <matthew.dovey@las.ox.ac.uk>
- Date: Mon, 14 Aug 2000 14:13:45 +0100
- To: "'www-zig@w3.org'" <www-zig@w3.org>
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