Zebedee — a simple, free, secure TCP and UDP tunnel program
zebedee -P [-p] [-f file]
zebedee -H string ...
Zebedee is a simple program to establish an encrypted, compressed “tunnel” for TCP/IP or UDP traffic between two systems. This allows data from, for example, telnet, ftp and X sessions to be protected from snooping. You can also use compression, either with or without data encryption, to gain performance over low-bandwidth networks.
This document describes the features of Zebedee as at release 2.4.1. For details of the new features in this release see CHANGES.
The main goals for Zebedee are to:
Of course, Zebedee is by no means the first, or only secure tunnel program available. It does not pretend to compete with the likes of ssh or SSL in terms of breadth of function but if you want something quick, simple and completely free then it may be the tool for you.
In case you were wondering, or even if you weren’t, Zebedee is named after its three main components:
So now you know!
To set up a secure connection between your local machine and a remote host you need first to run Zebedee in server mode on the remote system. The easiest way to do this is to run Zebedee with the -s option (but please read the notes on security issues later):
zebedee -s
If all goes well (and it should!) Zebedee will detach from the terminal (or console window under Windows) and run in the background. It will then be listening for incoming requests from clients.
On your local machine you then run Zebedee in client mode. You need to
specify the name of the remote machine and the name of the service or number
of the port to which the tunnel should be established — we will call this
the “target” port. If the remote machine is called remhost and you want to
set up a secure telnet session then you would run:
zebedee remhost:telnet
In fact, if you don’t specify a service or port the default is telnet so
zebedee remhost
would do just as well in this instance. When you run this command it will
print out a message telling you the port number which is the local end of the
tunnel. Zebedee will then detach from the terminal and run in the
background waiting for you to connect to the local port. If, for example, the
port number it printed out was 1234 then to connect to remhost using the
secure tunnel you would run:
telnet localhost 1234
By default, Zebedee will continue to listen for connections and tunnel them, handling multiple simultaneous connections if necessary, until you terminate the process.
Sometimes you will want to start Zebedee and then run a command that connects to the port straight away. You can do this in a single invocation of Zebedee as follows:
zebedee -e "telnet localhost %d" remhost
The “%d” in the string is automatically replaced with the local port number
so there is no need for Zebedee to print it out. If you specify a command
like this then the local Zebedee client will exit once the command closes
its connection.
You may want or need to control the local port number that the client uses. This is necessary if the command whose connection you are trying to protect expects to connect only to a specific port. In this case you can also specify the local port number by invoking Zebedee as follows:
zebedee clientport:hostname:targetport
So, for example, the command:
zebedee 8000:webhost:80
will allow you to secure all HTTP connections to webhost if accessed via port 8000 on the client system. See EXAMPLES for more details.
You can also use a single Zebedee client to handle multiple simultaneous tunnels to different target ports on the same remote host. In this case the client and target port specifications are lists of ports. For example:
zebedee 9001,9002,9003:somehost:daytime,telnet,ftp
This will tunnel traffic on the clientport 9001 to the daytime port on the remote target system, traffic on 9002 to the telnet port and traffic on 9003 to the ftp port.
This combination of client listening ports, target host and destination ports is called a “tunnel specification”. See the tunnel keyword for more details.
Originally Zebedee was designed only to be able to handle TCP/IP traffic. It can now also handle connectionless UDP data. To enable this start Zebedee with the -U option (or use the ipmode keyword). For example:
zebedee -s -U
on the server host and
zebedee -U 10000:somehost:echo
on the client. When run in this way Zebedee will handle both TCP and UDP traffic.
The tunnel between Zebedee clients and servers still uses a TCP/IP connection even in UDP-mode. This connection is timed out after a certain period of inactivity. It must be re-established if more data arrives. For this reason the performance in UDP mode may appear poor, depending on the nature of the application using it. You should note that there is also a limit on the size of UDP datagrams that can be handled.
For further details see the maxbufsize, ipmode, udptimeout and tcptimeout keywords.
Usually there will only be two systems involved when you set up a tunnel using Zebedee. You will run a client on one and communicate with it via connections to local ports. On the other you will run a server which will speak to services local to that machine. However, there can be up to four different systems involved, as shown below:
[source] <===> [client] <=====> [server] <===> [target]
| | |
+- insecure | + insecure
connection | connection
+- secure tunnel
The Zebedee client runs on the “client” system and the server runs on the “server” host. The inital connection that causes a tunnel to be established between client and server originates from the “source” machine. This could be a different system than where the Zebedee client is running, although it is usually the same. The server will ultimately communicate with the “target” system. Again, this is usually the local machine but does not have to be.
Most of the time you will not have to be concerned with the distinction between source and client and server and target. The terminology is, however, reflected in a number of the keywords described in the following section so you should bear it in mind when reading their descriptions.
In addition to the different systems involved in Zebedee tunnel there are also several different types of keys used to secure connection. The client and server generate or are provided with private key values. These are used to calculate public values which are exchanged and used to derive a shared secret key using the Diffie-Hellman key agreement mechanism. From this shared key a unique session key is derived to secure an individual connections between client and server.
A single Zebedee client/server pair can handle tunnels for multiple targets, not just the system on which the Zebedee server is running.
When a server is started it can be given a list of valid targets either on the command-line or by using the target keyword. Each target is a host name optionally followed by a list of ports to which connections may be made. Consider the following command run on a machine called serverhost:
zebedee -s target1:daytime,telnet target2:telnet target3
the server will allow connections to the daytime and telnet ports on target1, the telnet port on target2 and any port on target3.
Given this server invocation, a client may be started as follows:
zebedee serverhost 10000:target1:telnet 20000:target3:telnet
This will connect to the Zebedee server on serverhost and use it to establish tunnels to the telnet port on target1 via the client port 10000 and tunnels to the telnet port on target3 via 20000. Note that the name of the host on which the server is running is given as the first parameter. If the server name is omitted it is determined from the first tunnel specification. So if the server had been running on target3 then the above command could have been given as:
zebedee 20000:target3:telnet 10000:target1:telnet
In fact, a server also maintains a notion of a default target. This is the
host name of the last target specified. In the example server invocation
above the default target becomes target3. This is the target used when the
server and target names specified by the client are the same. Be careful of
this because you may get results that you do not expect. For example, if the
server was started on target3 as:
zebedee -s target2:telnet target3 target1:daytime,telnet
then the following client invocation:
zebedee 20000:target3:telnet
would result in connections to port 20000 being tunnelled to target1 and not target3. This is because when the server and target specified by the client are the same then the traffic goes to the server’s default target. To avoid confusion, if you want to include the server host in a list of multiple destinations then always name it last. Note that as well as a default target host it is also possible to specify a list of default allowed target ports where none are otherwise given. See the redirect keyword for more details.
As with the target keyword for the server, the equivalent of the command-line parameter for the client is the tunnel keyword (and serverhost in order to specify the server host explictly).
In normal use a Zebedee client inititates connections to the server when a connection has been made to it from a source system. Sometimes, for example when using Zebedee through a restrictive firewall, it may be necessary for the server to initiate the connection back to the client — to operate in “reverse.” For details on how to do this see the clienthost and listenmode keywords.
The behaviour of Zebedee is probably best controlled through the use of a configuration file. A configuration file can be specified using the -f command-line option. The file is read at the point at which the option is encountered so later command-line options may override the contents of the file.
Lines are of the form:
keyword value # optional comment
The keyword is a single, case-insensitive word. The value is either a single
word or a string. Strings are enclosed either in double quotes ("like
this") or single quotes (’like this’). Double quotes may appear in single
quoted strings and vice versa ("here’s an example"). Case is preserved in
the values where appropriate.
Blank lines and lines beginning with a “#” (after any leading whitespace)
are ignored. Long strings may be continued onto the next line by ending the
line with a “\” character. This character is eliminated and the next line
is joined on to the end. Note that there is a limit of a total of 1024
characters on any line and its continuations. Line continuation happens before
anything else, including comment recognition so the lines:
server false # This comment continues on the next line \ server true
will leave the value of server as false.
The keywords and their meanings are as described below. There is a brief description of all the keywords in the Quick-Reference Summary section. Some, but not all, keywords have equivalent command-line options. These are shown where available. There are also a few command-line options that have no equivalent in the configuration file. These are described at the end of this section.
If a keyword is described as being a boolean then its value must be one of the words true or false.
Several keywords require a list of ports to be specfied. Where this the case
the value is string that consists of a comma or white-space delimited list of
port names, numbers or numeric ranges. For example “telnet, ftp 5900-5903”.
This is equivalent to the list “23,21,5900,5901,5902,5903”. You can also
specify that a particular port or range should only be used for TCP or UDP
traffic by suffixing it with “/tcp” or “/udp”. If this suffix is omitted
it can be used for either type. So, the list “telnet/tcp,daytime/udp,echo”
specifies TCP-only traffic to the telnet port, UDP-only traffic to the
daytime port and either to the echo port.
A number of the keywords are either only applicable to clients or only applicable to servers. The same Zebedee program runs as either client or server and will silently ignore inappropriate options for the current type of usage. The choice of client or server behaviour is controlled by the server keyword:
The following keywords apply only to Zebedee clients:
%d”
this will be replaced at run-time with the local port number (see the
tunnel keyword). As this is done using sprintf
the conventions of that routine apply with regards to escaping “%”
characters (i.e. use “%%” to generate a single “%”). In addition,
specifying more that one “%d” or other format sequence will very likely
crash the program.
Once the command closes its connection Zebedee will exit. Using this keyword or option implicitly turns off multi-use mode (see multiuse). You can not use automatic command spawning when a single Zebedee client is handling multiple connections in multiuse mode or when a list of ports has been specified with the tunnel keyword or on the command-line.
The listenmode keyword, if true, causes a Zebedee client to listen for connections initiated by the server rather than to connect directly. The client will listen for connections at the network level but the connection from the server will not be fully accepted and activated until a matching connection from the source system has been received. Equally, a client will accept connections from source clients but no data will be read from or sent to these connections until a connection has been made with a server.
Normally a client makes a connection to a specific server address. Server-initiated connections could, however, originate from arbitrary addresses, thus giving the client no control over the destination of the tunnel. To avoid this the client will validate that the address of the server’s connection matches that specified, whether on the command-line, via the serverhost keyword or as part of the first tunnel specification. (The client can also use the checkaddress keyword to perform such checking).
When using listenmode the server address can also contain a network mask. So the following client invocation:
zebedee -l 10000:10.10.10.0/24:telnet
will accept connections from any address on the 10.10.10.0 class C subnet.
As a special case, if the server name is “*” then connections will be
accepted from any server address. Use of the identity checking features is also recommended to ensure that the correct server
connects.
If a connection from a server is not received within a certain period then the connection back to the source system will be closed and the process abandoned. This timeout is controlled by the connecttimeout keyword. The default is 300 seconds.
See the clienthost keyword for the description of the server side of this process.
The default is for this value to be false and for connections to be allowed from any arbitrary source machine.
This has been superseded by the more generic listenip
keyword. So “localsource true” is equivalent to “listenip 127.0.0.1”.
The command-line -m option is equivalent to setting this to true. This is the default behaviour in the current version of Zebedee and the option is retained only for backwards-compatibility reasons.
Any client listening on multiple ports will automatically run in “multi-use” mode, even if this is set false (see clientport).
See the listenmode keyword for the treatment of this value when using server-initiated connections.
Prior to version 2.0.0 this was known as the remotehost keyword. This is still recognised for backwards compatibility.
10000-10002:targethost:echo,telnet,daytime
The first part is the list of ports on which the Zebedee client will listen for connections. The second part is the name of the target host to which the tunnelled data should be directed. The final part is the list of target ports that correspond to the ports on which the client is listening. The numbers of entries in the client and target port lists must match.
As a special case, if only a single tunnel specification is given with only a single target port then the client port list (and separating colon) may be omitted. The client port will be assigned automatically (and a message will be printed to the terminal giving the port number). This is to allow for backwards compatibility and for use with the command keyword. If the target port is also omitted then it will default to telnet (port 23).
As described in the section Multiple Destinations if the Zebedee server host is not explicitly specified, either as the first argument on the command-line or via the serverhost keyword, then it will be taken from the first tunnel specification found.
There is also one final variant of the tunnel specification. In this case the
targethost is replaced by a “*”. This wild-card form is used either with
the client running in “listen-mode” (see listenmode for
further details) or when you want to specify tunnelling to the server’s
default target, whatever it may be. This latter form is useful in a
configuration file when you want the file to be generically applicable to any
server. For example, a file like this:
server false tunnel 10000:*:daytime tunnel 20000:*:echo tunnel 30000:*:telnet
can be used to set up tunnels on ports 10000, 20000 and 30000 to whatever host may be specified on the command-line like this:
zebedee -f configfile serverhost
The following keywords apply only when running as a server:
Each time a connection has been accepted by the client the server tentatively opens up another one so that the client could establish further tunnels if necessary. If the connection is not accepted within a certain period then it will be closed and the server will exit once all currently active tunnels have been closed. The timeout is controlled by the connecttimeout keyword. The default is 300 seconds.
Note that Zebedee does not itself provide a mechanism for co-ordinating the starting of client and server to set up a “reverse” tunnel. That must be handled by some “out-of-band” mechanism.
telnet, ftp, 5900-5910”.
If no redirect keyword is specified then requests to redirect traffic to
any port will be accepted. While this is convenient for testing it may pose
a security risk so you should specify an explict list of allowed ports if at
all possible. As a special case, if the port range is given as “none” then
any current default redirection list will be cleared and no target ports will
be accepted by default.
The keyword (or -r option) may be specified multiple times in which case redirection will be allowed to any of the ports specified.
It is generally better to use the target keyword instead of redirect, where possible. The main reason to prefer redirect is when you want to specify a common range of ports for a number of targets, for example:
# Set up common target redirections redirect telnet,ftp,daytime target hosta target hostb target hostc # Set up additional host-specific redirections target hostb:http
target www.winton.org.uk:http,ftp
If the port list (and colon) are omitted then requests for redirection will be controlled by the ports given by the redirect statements, if any.
The target hostname may also be specified as a CIDR network address, that is an address with the number of bits to be used for the network mask, for example:
target 10.10.10.0/24:http
This means that HTTP connections to any host address in the 255-host class C subnet will be accepted.
This keyword is equivalent to the comnmand-line arguments of the same form (see Multiple Destinations). It may be repeated multiple times. The final target host specified, either using the this keyword or on the command line, becomes the default destination for tunnels when a client specifies the server’s host-name as the destination.
Be careful when using CIDR addresses as targets that the last target specified will be valid default address. If the default target has an address mask then Zebedee will flag this as an error and exit.
This functionality will not work on all platforms and Zebedee will have to
be run as a privileged user (e.g. root on UNIX-like systems) in order for
it to work at all. Full transparency support for TCP and UDP traffic is
currently only expected work on Linux and then only on systems with kernel
versions 2.0 and 2.2. It will not work on Linux 2.4, although there is some
hope that it may work in future versions.
Support for a limited form of transparency for UDP traffic is available for a
wider range of UNIX-like platforms, although this must have been enabled at
compile time. If it has been enabled then unidirectional UDP traffic from
client to server will preserve the Zebedee client’s IP address on datagrams
sent to the target server. This will be sufficient for applications such as
syslog where there is no requirement that the target server should reply to
such traffic. Applications that attempt to reply to the address in these
datagrams will not send replies via the Zebedee tunnel and, in fact, are
likely to send their data to non-existent or invalid endpoints.
The following keywords control the compression and encryption of data passing through the tunnel. They apply to both clients and servers:
zlib”
or “bzip2” and level is an integer from 0 to 9. As a special case an
integer without any prefix implicitly selects a zlib compression level.
The level specifies the maximum compression level to used (9 is the maximum
and 0 is no compression). The actual compression level used will be the
minimum of the client’s and server’s values. For these purposes all bzip2
levels (except 0) are considered to be greater than all zlib levels so if
either client or server does not support bzip2 the protocol degrades
gracefully to using zlib. The default compression value is “zlib:6”.
Note that, because of the way that bzip2 compression works and the buffer sizes that Zebedee uses, bzip will probably only be useful if continuous streams of data are flowing. On smaller transfers, such as those in a normal telnet session, zlib will usually win. You will have to experiment to see what works best for you. In addition, because the buffer size is small there is no gain from using bzip2 levels above 1 and Zebedee will round any higher values down to this level.
You can see exactly how much compression is gaining you at verbosity levels 2 and above when basic statistics are printed out on connection termination. For example:
zebedee(232/210): read 166 bytes (265 expanded) in 3 messages zebedee(232/210): wrote 20969 bytes (30499 expanded) in 247 messages
passphrase.tcl) that prompts a user for a pass-phrase and then uses this
to generate an appropriate key is included in the standard Zebedee
distribution. If might be used as follows (wish is the Tcl script
interpreter):
keygencommand "/usr/bin/wish -f passphrase.tcl"
If a privatekey value is specified it takes precedence over any keygencommand.
Briefly, on UNIX-like systems the level-2 key generation mechanism uses
/dev/urandom or /dev/random, if either of these devices is available, to
obtain good pseudo-random data based on the state of the running kernel. If no
random-data device is available or the level is set to 1 then data from the
current contents of the /proc file-system, if there is one, will be used
otherwise at level 0 only data from the current process will be used.
On Windows systems there is currently no distinction between different key generation strength levels and this keyword is effectively ignored.
The default valuse is 128. As a special case setting this value to 0 will turn off key negotiation and encryption.
This keyword specifies how long a shared secret key is valid before it must be renegotiated. This does not affect connections that have already been established, only new connections.
The value is in seconds and must be less than or equal to 65535, which is a little over 18 hours. By default it is set to 3600 seconds (one hour). Setting this value to zero effectively disables the use of reusable keys and a full negotiation of a shared key will be performed for each connection — assuming that both client and server also generate a new private key each time. This will impact performance and is recommended only if you have a very high paranoia level!
The default value is zero.
The default modulus is the 1024-bit prime:
f488fd584e49dbcd 20b49de49107366b 336c380d451d0f7c 88b31c7c5b2d8ef6 f3c923c043f0a55b 188d8ebb558cb85d 38d334fd7c175743 a31d186cde33212c b52aff3ce1b12940 18118d7c84a70a72 d686c40319c80729 7aca950cd9969fab d00a509b0246d308 3d66a45d419f9c7c bd894b221926baab a25ec355e92f78c7
This was taken from the file testdh.h in Peter Gutman’s CryptLib. The comment in this code says that the value was among those “generated by Colin Plumb for SKIP”. It further says that “these values were chosen as representative well-known public values to allay fears of possible trapdoors in self-generated values. The generation method and actual values can be checked against the SKIP standards document.”
All clients and servers that wish to communicate must use the same shared secret key value. Connections between clients and servers that do not share the same secret will be terminated before a tunnel is established. It is your responsibility to distribute and protect this secret from disclosure.
The following keywords apply equally to clients and servers:
When a connection is established between a client and a server the IP address and, optionally, source port of the system at the other end of the connection is checked against the set of specified addresses and ports. If it does not match any of the entries the connection will be closed. So, for example, the entry:
checkaddress 192.168.1.0/24 checkaddress 192.168.2.0/24
in a server’s configuration file would only permit connections from systems on the two subnets named. This checking is done before any further validation of identity (see identity checking).
Please note that source IP addresses can easily be “spoofed” and you should not place great reliance on this for validating the identity of a client or server. It is, however, a useful basic protection mechanism.
If a keylength of zero has been agreed then no identity checking will be performed.
Note that this setting will not work correctly in UDP mode, so don’t bother trying it!
Note that this does not always seem to work from an interactive command prompt under Windows systems. The symptom is that output to the console window will stop and interrupt signals will be ignored but the console prompt will not be issued until Zebedee terminates. In order to work around this you can use the “start” command as in the following example:
DOS> start zebedee -f server.zbd
This will start Zebedee in a new console session from which it will then detach. You may see a console window appear briefly before it detaches but Zebedee should be running in the background when it disappears.
read 39 bytes from local socket 324 < 0000 00 00 00 # ff S M B a2 4 00 00 c0 98 07 c8 < 0010 00 00 00 00 00 00 00 00 00 00 00 00 01 08 d0 03 < 0020 01 08 p 00 00 00 00
Lines beginning with “<” or “>” show the data that is being is
read from or written to the local socket. Each line shows up to sixteen bytes
of data and is prefixed by the offset, in hexadecimal, from the beginning of
the data stream. Printable ASCII characters are shown verbatim, such as the
three characters “SMB” above, while other bytes are shown as a hexadecimal
value.
httpproxy webproxy.example.com:8080
There is no default port, you must always specify one explicitly. The proxy can be used for either client or server-initiated connections (see listenmode). Source or target connections are unaffected, the proxy only applies to connections between a Zebedee client and server.
Please note that using an HTTP proxy server to tunnel arbitrary connections is very likely to violate the security policy of the organisation running the server. If you intend to use Zebedee in this way (or, for that matter, to establish any other kind of “backdoor” tunnel) I strongly advise you to seek permission from the appropriate network administrators.
In order to give administrators some chance to maintain proper control over
the use of their proxy servers Zebedee does identify itself with a
user-agent string of Zebedee when it connects to the proxy server. Well, it
does in the “official” version anyway.
The default value is tcp and Zebedee will only handle TCP traffic in
this case. The value udp is equivalent to setting
udpmode to be true. In this case only UDP traffic will
be handled and the Zebedee server will, by default use a different port
(11230). If it is set to both then a client will listen for both TCP and
UDP traffic and a server will handle requests to tunnel both TCP and UDP
traffic. In this case the server uses only one port, by default the normal
TCP-mode port of 11965. The command-line option -U is equivalent to
“ipmode both”.
Please be aware that a client or server running purely in UDP mode will expect to use port 11230 by default. If the corresponding Zebedee server or client is running in “mixed” mode you may have to specify the port explictly. For example, if the server is running in mixed mode:
zebedee -s -U
then a client running in UDP-only mode will need to specify the server port:
zebedee -u -T 11965 10000:serverhost:echo
The address can be given as a “dotted quad” or by name but in the case where the name can resolve to multiple IP addresses the results may be unpredictable. The address must, obviously, also correspond to one of those belonging to the system.
Note that listenip is a more general form of localsource and setting localsource will override listenip and vice versa.
By default Zebedee attempts to read data from the client or server programs at each end of the tunnel in chunks of 8192 bytes. There may be occasions when you want to decrease this if, for example, you have a highly interactive application and the response seems sluggish because you end up waiting for large data transfers. You can reduce the buffer size to one byte, but unless you are trying to debug misbehaviour or have time to waste I don’t recommend it! Conversely, you may increase the buffer size up to a maximum of 16383 bytes to attempt to gain the most from data compression where large blocks of data are being transferred. Note that the maxbufsize value does not affect how much memory is allocated by Zebedee, only the size of data chunks read.
When running in UDP mode this buffer size will also affect the maximum size of any datagram that can be handled. Datagrams larger than the current buffer size will be fragmented, which will likely cause whatever application is consuming them to fail. Datagrams larger than 16383 bytes can not be handled at all.
Two special “file names” are also recognised as valid values. If the name is NULL the all messages will be turned off. If the name is SYSLOG then messages will be written to the host system log. On Windows systems this is the system application event log. Elsewhere messages are written to the syslog service.
This value represents a time limit in seconds within which reads from a Zebedee tunnel must be complete. If the value is zero then no timeout is applied. This is the default behaviour because applying a timeout will have some impact on performance and an unnecessarily small timeout may cause valid connections to fail.
The timeout primarily affects the initial Zebedee protocol exchanges. If you wish to cause valid but apparently idle connections to be timed out you should use tcptimeout or udptimeout.
If using server-initiated connections (see listenmode and clienthost) then this is also the port on which the client listens for the server’s incoming connections.
See also idletimeout and udptimeout.
The tunnel between Zebedee clients and servers still uses a TCP/IP connection. A separate connection is established for each different originating UDP network endpoint. Because UDP is connectionless there is no easy way to tell when the data traffic has been completed. For this reason the Zebedee connection must be timed out after a period of inactivity. This period is controlled by the udptimeout value.
If more data subsequently arrives from a source the tunnel for which has been timed out, the connection must be re-established. For this reason the performance in UDP mode may appear poor, depending on the nature of the application using it. Altering the keylifetime value may improve this by minimizing connection setup times and changing the udptimeout value may also help.
The command-line -u option is equivalent to setting this to true. It is also equivalent to setting ipmode to udp.
See also idletimeout and tcptimeout.
Messages are written to stderr (unless redirected using the -o command-line option or logfile keyword). The general form of messages is something like:
zebedee(54/119): Listening on local port 1172
The numbers in brackets represent the process and thread identifiers of the
code logging the message. All error messages are logged at level 0 and are
preceded by the word ERROR, as follows:
zebedee(54/119): ERROR: failed to connect to localhost:11965
Messages are indented according to the level at which they are logged.
As Zebedee has evolved over time some of the keywords have been changed to reflect this. In a few cases keywords have been superseded and made obsolete. These obsolete keywords are still recognised in order to retain backwards compatibility with old configuration files but they should not be used in new ones.
This is the port or list of ports on which the Zebedee client will listen for connections. It is equivalent to the first part of a tunnel specification.
This keyword gives the name of a host to which a Zebedee server will redirect all incoming tunnelled data, rather than to ports on the local machine.
It gives the port or list of ports to which the client will request that Zebedee server should establish connections on the target host. It is equivalent to the final part of a tunnel specification.
There are a few command-line options that have no equivalent in the configuration file. These are described below.
zebedee -F~ -x "message~’Hello,~World!’"
will output a message like the following:
zebedee(1128/1348): Hello, World!
Please be aware that you can specify any character as a separator. It is your responsibility to ensure that the character you choose does not conflict with any other usage in the configuration file.
privatekey "c480bd48f707c69dec54c9e7b6e22dd04cac659e"
ef8153a0e392df005f67321ca2f0ace5bb8c5a1f myhostname
This option must either be specified with a configuration file that contains a private key value or must be used in conjunction with -p to generate private and public keys simultaneously.
-” then the
standard input is read and the hash of that is calculated. For example:
$ zebedee -h /etc/passwd bb1e734aeffd2111417761f5938dea3b53759598 /etc/passwd $ zebedee -h < /etc/passwd bb1e734aeffd2111417761f5938dea3b53759598 -
$ zebedee -H hello world ac62a630ca850b4ea07eda664eaecf9480843152 hello 86bf25ecb8a40b40b885c097c683b6e236fc8085 world
Zebedee can be installed as a service by specifying the install parameter with the name of a configuration file, for example:
zebedee "-Sinstall=c:\zebedee\service.zbd"
You should always specify the full path to the configuration file. This will be read at service start-up and must contain all the parameters required for the service to run. Note that if the path contains spaces you must enclose it in double quotes, as shown.
By default, the name of the installed service will be taken from the name of the program file, and hence is usually zebedee, but you can change this by using the -n option:
zebedee -n "Zebedee Client Service" "-Sinstall=c:\zebedee\clientsvc.zbd"
Once the service has been installed it will be automatically started the next time that the system reboots. Alternatively you can start it manually using the Service Control Panel (under Windows NT).
To remove the service specify first stop it and then use the remove parameter to the -S option, along with any necessary service name using -n. For example:
zebedee -n "Zebedee Client Service" -Sremove
There is one further valid parameter to the -S option and this is run. This is used internally by Zebedee to invoke the service start-up code and should not be used directly.
zebedee -x " server true # It’s a server!"
is a rather perverse way of achieving the same effect as:
zebedee -s
The following table lists the recognised keywords, their argument types, command-line equivalents, validity for client, server or both and a brief description.
checkidfile filename CS Checks peer identities against this file
clienthost hostname -c S Server initiates connection to client host
command string -e C Specified command to run connected to tunnel
compression level -z CS Requested maximum compression level
connecttimeout seconds CS Timeout for connections to be accepted
debug boolean CS Run in single-threaded "debug" mode
detached boolean -d CS Detach from the terminal/console
generator string CS Hexadecimal Diffie-Hellman generator value
httpproxy host:port CS Make connections via the given HTTP proxy
idletimeout seconds CS Inactivity timeout for all tunnels
include filename -f CS Read in the named configuration file
ipmode type -U CS Run in TCP, UDP or "both" mode (-U = both)
keygencommand string CS Command to run to generate key
keygenlevel level CS Key generation strength level (0 to 2)
keylength bits CS Requested maximum keylength in bits
keylifetime seconds CS Lifetime of shared secret keys
listenip address -b CS Listens only on the specified IP address
listenmode boolean -l C Client listens for server connections
localsource boolean C Only accepts connections from local machine
logfile filename -o CS Set the output log file
maxbufsize bytes CS Specify buffer size for data reads
message string CS Output the specified string
minkeylength bits CS Acceptable minimum keylength in bits
modulus string CS Hexadecimal Diffie-Hellman modulus value
multiuse boolean -m C Handle multiple connections
name string CS Specify the name of the program
privatekey string CS Hexadecimal private key string
redirect ports -r S Ports to which server will redirect traffic
server boolean -s CS Selects server-mode or client-mode
serverhost hostname C Name of server host to which to connect
serverport port -T CS Set the port on which the server listens
sharedkey string CS Hexadecimal shared secret key string
sharedkeygencommand
string CS Command to run to generate shared key
target spec S Specifies allowed target host and ports
tcptimeout seconds CS Inactivity timeout for TCP tunnels
timestamplog boolean -t CS Add timestamps to the log file
tunnel spec C Specifies client ports and matching targets
udpmode boolean -u CS Handle UDP traffic only
udptimeout seconds CS Inactivity timeout for UDP tunnels
verbosity level -v CS Set the message logging level
Other options that have no keyword equivalents:
-F char
Specify an additional field separator (whitespace) character
-p Generate a private key
-P Generate a public "identity"
-h file ...
Hash file contents and print results
-H string ...
Hash string arguments and print results
-Sinstall=file
Install Windows service with specified configuration file
-Sremove
Remove Windows service
-x string
Parse option string
By default Zebedee just establishes an encrypted channel between two points. While you know that the data is protected from snooping “on the wire” there is no guarantee that the tunnel ends up where you think it does. By default, and unless you are applying any other kind of filtering or firewalling, a Zebedee server will accept connections from any client that can reach it. If the service to which you are tunnelling does not provide any further authentication, or if it relies on checking the source IP address, then it will be potentially open to attack.
The simplest, but most basic check, that you can make is to restrict the IP addresses from which a server will accept, or to which a client will make, connections. You can do this by using the checkaddress keyword.
IP address checking is useful but not that secure. Zebedee is also open to open to “man-in-the-middle” attacks where an eavesdropper pretends to a client to be the server and intercepts all traffic before forwarding it on to the real server. If you are concerned primarily with using data compression or protecting against casual “network sniffing” then you may be happy with this situation. If, however, you want more assurance that your connection is not being “hijacked” then Zebedee provides some basic facilities for doing so.
A Zebedee server can validate the identity of the client at the other end of a tunnel provided that you are using an encrypted connection. To do so the client must use a fixed private key. The easiest way to generate such a key is by using the -p option, like this:
zebedee -p
This will output a line something like this:
privatekey "410dea0cbd9c10da057848c43a610f6bb859b769"
The string of hexadecimal digits will be different every time you run it. So, on your client system you should generate a key and save it in a file, for example:
zebedee -p > myclient.key
The file myclient.key now contains the private key that will be used by
Zebedee on this system. The private key must be kept secret so you should
apply appropriate protection to this file to stop unauthorised users accessing
it. You now need to generate the public “fingerprint” associated with this
key, which you can do as follows:
zebedee -P -f myclient.key > myclient.id
The contents of the file myclient.id will look something like this:
135f04050961d37553731250d5c6f7495f088b32 myclient
The text after the string of hexadecimal digits will be the name of the machine on which you run this. It’s just a descriptive tag so you can change it to be, for example:
135f04050961d37553731250d5c6f7495f088b32 Neil’s PC
You should now modify your client configuration file to add a line:
include "path-to-dir/myclient.key"
where “path-to-dir” is the directory in which the key file is being kept.
The myclient.id file is used by any server that wishes to validate the
identity of myclient. The contents are not secret and you should copy this
file to the Zebedee server.
On the server you should add the contents of myclient.id to a single file
containing the identity “fingerprints” of all clients you wish to validate.
This file, for example called client.idlist, might look like this:
ba077f6a42bea502f517cab5685e476a713d9621 Rebecca’s PC 3ad38cb1f16957d5c535272ce27557bdaa4389c6 Ben’s PC 135f04050961d37553731250d5c6f7495f088b32 Neil’s PC
Now, to the server configuration file add the following line:
checkidfile "path-to-dir/client.idlist"
That’s it! Now only clients whose identities appear in this file will be able to create tunnels to the server. If you remove a line the client will be denied further access.
At the moment you can only have a single identity file and it is an “all or nothing” mechanism — a client can either create a tunnel to any valid target or to none at all. This may be enhanced in future.
It is also worth noting that this mechanism can equally well be used for a client to validate the identity of a server, if the server uses a fixed private key.
By default, Zebedee generates a new private key every time it is started. If the same modulus, generator and private key are used they will always generate the same public value for use in the Diffie-Hellman key exchange protocol. The “fingerprint” is a hash of the modulus, generator and public key. Only a person knowing the private key will be able to produce public key and successfully decrypt traffic. So, if the same combination of modulus, generator and key are seen then the identity of the client can be tied to the owner of that private key. The modulus, generator and key strings are hashed together to produce the fingerprint merely for convenience and to keep the size of the identity file small.
ls -l” into
“rm -f” — but do not depend on Zebedee to protect your application from
the effects of being fed random data!
When Zebedee is operating in “anonymous” mode the risk of such an attack being successful is low because different private keys will be generated every time Zebedee is used. However, if the identity checking features are used the keys will be fixed and replay could be a possibility. Zebedee protects against this by generating a unique session key for each connection. Following that, the final part of the connection setup also involves a challenge-response exchange that verifies that the system at the other end of the connection really knows the shared secret key and is not just parrotting back previously recorded data.
In addition, Zebedee uses Blowfish encryption in “cipher feedback” mode which means that decryption of any part of the data depends upon successful decryption of all the data packets that have gone before it. The challenge-response exchange “salts” the data-stream so even if the protocol being tunnelled is determined a “known plain-text” attack is made more difficult.
On Windows the available state data is somewhat more predictable, particularly if an attacker has access to the system. Having said that, it should be quite acceptable for most purposes. The comments in the code explain this in more detail if you are interested.
If you are unhappy with the key generation mechanisms then you should call out to an external key generation program using the keygencommand option in a configuration file. Suggestions for improving the built-in capabilities will also be gratefully received!
Although Zebedee should work “out of the box” you might encounter some problems. These are most likely during connection setup — once that has been accomplished the data transfer generally goes smoothly. The eaisest way to see what is happening during the setup process is to use the -v option. You will usually want to combine this with the -d and -D options to stop Zebedee from the terminal and to force it to handle only a single connection at a time. So, for example, you might use the following command to start up a server:
zebedee -dD -v 3 -s
Setting the logging level to 3 should show you the main exchanges during connection setup. If you believe there is a problem after this then levels 4 and 5 will show you what message traffic is being exchanged.
In the Zebedee distribution there are a number of example configuration files. The following sections describe how they can be used as well as how to use Zebedee to tunnel some specific protocols.
There is an example server configuration file (server.zbd) shipped with the Zebedee distribution. This shows most of the common options.
# # Sample Zebedee server configuration file # # This shows the use of many, but not all, of the configuration file # options available for use by a server. #
verbosity 2 # Slightly more than basic messages
# Comment out the following line once you have read the comments # in this file and enabled or disabled the appropriate options!
message "DEFAULT CONFIGURATION FILE -- EDIT BEFORE USE"
detached false # You will probably want this ’true’ for normal
# use but I want to make sure that you see the
# preceding message if you haven’t edited this.
server true # Yes, it’s a server! ipmode both # Operate in mixed TCP/UDP mode
compression zlib:9 # Allow maximum zlib compression keylength 256 # Allow keys up to 256 bits keylifetime 36000 # Shared keys last 10 hours maxbufsize 16383 # Allow maximum possible buffer size
# Uncomment the following line to log messages to a local file. # # logfile ’./server.log’ # # Or to log to the system logging facility uncomment this: # # logfile SYSLOG
keygenlevel 2 # Generate maximum strength private keys
# Uncomment the following line if you want to use a fixed private # key stored in a static file. The file should contain a line of # the form "privatekey hexadecimal-key-string". This file should # be readable by the user running Zebedee but no-one else. # # include ’./server.key’
# To validate the identity of clients use a line something like # the following: # # checkidfile ’./clients.id’
# The "redirect" expression can be use to set the default ports # allowed when a target specification consists of a hostname but # no other ports. The "redirect none" statement prohibits # tunnelling anywhere by default.
redirect none
# Set up allowed targets. Note that there are NO targets allowed # by this file by default. You must explicitly edit it to enable # them.
# The following are good for testing purposes. Either TCP or UDP # are allowed. # # target localhost:daytime,echo,chargen
# Basic interactive services, TCP only. # # target localhost:telnet/tcp,ftp/tcp
# VNC traffic -- usually you will only need a subset of this # range, perhaps 5900 or 5901. # # target localhost:5900-5999/tcp
# X Window System -- again, usually you will only need # a subset of this range. # # target localhost:6000-6010/tcp
# Here is an example of specifying targets using a subnet. In # this case allowing tunnels to be established to VNC servers # on the 10.1.1.xx subnet. # # target 10.1.1.0/24:5900/tcp
# The following line ensures that the default target host # is the local machine. The last named host becomes the # default so leaving this here ensures that "localhost" is, # the default unless overridden on the command line.
target localhost
To test the identity checking facilities you can uncomment the checkidfile line and then use one of the supplied client1.key or client2.key files on the client side.
One of the reasons behind writing Zebedee was to use it over dial-up lines with VNC. VNC is a free system to provide remote display capabilities using a “remote frame-buffer” concept. You can use it to display Windows desktops remotely or, with an “Xvnc” server to access an “X desktop” from any VNC client machine, or even a Java-enabled browser! See http://www.uk.research.att.com/vnc/ for more details.
The supplied sample server configuration file server.zbd has sample target statements (commented out by default) that are configured to allow redirection of ports 5900-5999 which will allow tunnelling of VNC sessions. This file can be used on both UNIX and Windows but note that on Windows you must set the “AllowLoopback” flag in the registry in order for tunnelling to work. Saving the following snippet (without any leading spaces) in file a and then importing it into regedit will do the trick:
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3] "AllowLoopback"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3\Default] "AllowLoopback"=dword:00000001
You will find a file with these contents in the Zebedee distribution by the name vncloopback.reg. Having set these registry entries then the file vncviewer.zbd can be used to invoke a VNC viewer tunnelled to the host named on the command line. Here are the contents of the file vncviewer.zbd:
# # Zebedee configuration file to start up a tunnelled VNC session # # Usage: zebedee -f vncviewer.zbd remote-host:vnc-port #
verbosity 1 # Basic messages only
server false # It’s a client detached true # Detach from terminal
message "Starting VNC viewer"
# On Windows systems you might use the following:
command ’"c:\Program Files\ORL\VNC\vncviewer.exe" localhost:%d’
# On UNIX systems you might use the following:
# command ’vncviewer localhost:%d’
compression 6 # Request normal Zlib compression
So using this file as follows:
zebedee -f vncviewer.zbd somehost:5901
will start a VNC viewer tunnelled to the VNC server on somehost port 5901 (the server you would usually refer to in VNC-parlance as “somehost:1”).
VNC also supports a Java viewer. If the server is running on port 59xx then the viewer can be downloaded via port 58xx. However, it appears that the Java viewer communicates the main VNC port number to the client. So, to tunnel traffic when using the Java viewer you must make sure that the local and remote ports use the same numbers. So, for example, to tunnel traffic to a VNC server using port 5901 you should do something like:
zebedee 5801,5901:remotehost:5801,5901
This will be problematic if you already have a VNC server running locally on port 5901, but you can usually arrange local and remote VNC servers so that there is no clash.
There is one last point worth mentioning. If you are using compression with VNC it is worth experimenting a bit with the VNC protocol encoding. I have found that “raw” encoding often compresses best and sometimes gives better performance with Zebedee over slow links. But, as they say, your mileage may vary!
The X Window System uses ports in the range 6000 onwards.
Let’s assume that your local machine called xlocal is running an X server on port 6000. This would be the port normally used by the display known as xlocal:0. You now want to send a secure xterm session back to your local display from a machine called xremote. To do this you might run the following command on xlocal:
zebedee -s localhost:6000
Then on xremote you could run:
zebedee 6001:xlocal:6000
This means that if the DISPLAY environment variable on xremote is set to
localhost:1 then X traffic will end up on xlocal. So, for example, to
send a secured xterm session from xremote to xterm you would run a
command like this on xremote:
xterm -display localhost:1
Note that in order for this to work correctly you must also add an entry for localhost to the access control list for the X server on xlocal. You can do this by running the following command on xlocal:
xhost +localhost
Zebedee can be used to secure or just compress all traffic to and from a Web server. So, for example, if a Web server is running on the machine webhost on port 80 and it is also running a Zebedee server then the command:
zebedee 8000:webhost:80
will set up a tunnel via port 8000 on the client host. Now any URLs that previously were addressed via webhost, for example:
http://webhost/private/index.html
can now be accessed securely as follows:
http://localhost:8000/private/index.html
You could redirect all HTTP traffic via the secure tunnel by setting
“localhost:8000” as your proxy. Be careful, however, only to set this as
the proxy for HTTP connections — other protocols (including Secure HTTP)
should be directed elsewhere. It is also possible to configure most browsers
to use different proxies for different domains and so secure connections
selectively. Consult your browser’s documentation for details on how to do
this.
It is possible to protect the FTP control connection (over which the username and password are sent) for many FTP servers using Zebedee “out of the box” by following the instructions below. It may also be possible to protect the control connection for other servers and even “passive-mode” data connections by using Zebedee in conjunction with one of the techniques described below.
The simplest approach, which will protect the control connection and which works with some FTP servers, is to run the Zebedee server as follows:
zebedee -s ftpserverhost:ftp
Note that even if you are running Zebedee on the same machine as the FTP server you should explictly name it on the command line (or using the target keyword). Do not refer to it as localhost. On the client system you could then run Zebedee as follows to set up a tunnel via port 10000:
zebedee 10000:ftpserverhost:ftp
To connect to the FTP server you would then use a command like:
ftp clienthost 10000
Again, use the local client host name not, localhost. If your FTP client
does not support specifying the port on the command line, as is the case with
the standard Windows FTP client program, you may be able to use the command
“open clienthost 10000” from within the program. If you are not running
an FTP server on the client machine you could also try running Zebedee as:
zebedee ftp:ftpserverhost:ftp
and then just invoking the FTP client program as:
ftp clienthost
The approach just described will work for FTP servers that do not check that the FTP control and data connections appear to come from the same source. However, some servers such as the widely-used wu-ftpd are more strict about this — for good security reasons. If you can apparently establish a connection to the server but directory listing and file retrievals fail or hang then it is likely that your server is one of the strict ones.
If you find yourself in this situation then a good approach (suggested by
Magnus Wedburg) is to investigate your FTP server’s support for operating with
firewalls and Network Address Translation (NAT). Many modern servers,
including wu-ftpd, allow you to specify the address that a server will
report for itself in FTP requests. They will also allow you to specify a
range of ports which will be used for “passive mode” connections. If you can
specify these two values you should be able to use Zebedee to tunnel both
control traffic and also data traffic for passive connections. Support for
passive mode depends upon the particular FTP client being used. Netscape
Navigator and the Windows program WS_FTP are examples of clients able to do
this.
Assuming that you have the capability to specify the server response address
and range of ports you can the use Zebedee as follows. First, set the
response address to the localhost address, that is, 127.0.0.1. Then
select a range of ports to be used for tunnelling passive-mode data
connections. The size of the range will limit the number of simultaneous
connections that can be handled. In this case we will chose 30000-30010. Now,
on the FTP server run:
zebedee -s localhost:ftp,30000-30010
Then on the client run:
zebedee 2121,30000-30010:ftpserverhost:ftp,30000-30010
The value of 2121, for the FTP control connection, could be any other convenient port. The passive port range must, however, be the same as that on the server. To access the server with both control and data connections secured using Netscape you would then supply a URL of the form:
ftp://username@clienthost:2121/
where username is your user-name on the FTP server host.
If you can’t configure the target FTP server as described above then there is one more method that you can try. The Zebedee distribution contains an “FTP gateway” script called ftpgw.tcl. This is a program, written using the freely-available Tcl scripting language (see http://tcl.activestate.com) that intercepts FTP requests and re-writes them so that a server is shielded from the presence of Zebedee. You should run this on the same system as the Zebedee server. Assuming that the FTP server is also running on the same system you can just run this as:
tclsh ftpgw.tcl
This will start the gateway listening on port 2121. Obviously, in real usage you will probably want to start this in the background. You then start the Zebedee server as:
zebedee -s localhost:2121
Note that in this case you do specify the local host as the target. On the client side you can now run:
zebedee 2121:ftpserverhost:2121
followed by:
ftp clienthost 2121
You must still, however, use the client host name here.
This configuration will allow you to tunnel the FTP control connection but will not affect any data connections. Using ftpgw.tcl it is, however, also possible to secure the passive-mode data channels in a similar manner to that described above.
To secure passive-mode data connections you must choose a range of ports on the server that will be used for data connections. In this example we will again use 30000 to 30010. You then start ftpgw.tcl with the -p option to specify this port range:
tclsh ftpgw.tcl -p 30000-30100
The Zebedee server would then be started as:
zebedee -s localhost:2121,30000-30100
and the client as
zebedee 2121,30000-30100:ftpserverhost:2121,30000-30100
To access the server with both control and data connections secured using Netscape you would then supply a URL, identical to that shown above, of the form:
ftp://username@clienthost:2121/
This section outlines the main user-visible changes since the previous
“stable” release, 2.2.2. Full details, including bug fixes and other
non-visible enhancements, are in the CHANGES.txt file in the
Zebedee distribution.
The ipmode keyword and -U option have been added in
order to allow a single Zebedee client/server pair to support both TCP and
UDP traffic. Tunnel and target ports can now be suffixed with “/tcp” or
“/udp” in order to restrict the protocol used when running in “mixed” mode.
The listenip keyword (or -b command line option) now allows you to specify the local IP address at which Zebedee will listen for incoming connections. This useful on machines with multiple network cards.
Target specifications (see target) can now include
sub-nets, given in CIDR address format, such as 10.1.1.0/24. This allows
you to select a range of allowable targets with a single specification.
You can now permit or deny tunnel setup based on the IP address of the connected client or server by using the checkaddress keyword.
The redirect keyword now has an option none to turn off tunnelling to any default target ports.
Zebedee connections, both client and server initiated, can now be made via
HTTP proxy servers that support the CONNECT method by using the
httpproxy keyword.
There is partial support, with the transparent keyword, for a Zebedee server to attempt to act as a transparent proxy and forward on the client IP address.
The example configuration files shipped with the distribution have been “modernised”, to give better examples of newer features. The have also been made more secure “out of the box.” This may cause you an issue if you try to use the files without further modification.
An example key generation command, passphrase.tcl is included in the
distribution.
The new tcptimeout and idletimeout settings allow inactive TCP tunnels to be closed.
The readtimeout keyword has been added to allow some defence against denial of service attacks.
The -F option can be used to specify a new (in addition to whitespace) configuration file field separator character.
You can now specify an explicit shared secret key using the sharedkey and sharedkeygencommand rather than have Zebedee negotiate one itself. This, and the -F option, has been added primarily for use in Ed Suominen’s PRIVARIA (see http://privaria.org) secure communication suite.
Version 2.4.1 adds the dumpdata keyword to allow local data details to be shown in logging output.
The following information can also be found in the file LICENCE.txt in the Zebedee distribution.
Copyright (c) 1999, 2000, 2001, 2002 by Neil Winton. All Rights Reserved.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
A copy of the GNU General Public License can be found in the file GPL2.txt.
You may obtain the latest copy of Zebedee, including full source code from http://www.winton.org.uk/zebedee/ and other enquiries about Zebedee can be e-mailed to the author at zebedee@winton.org.uk
Zebedee would not have been possible without the use of a large amount of freely-available software to do all the really hard stuff. I gratefully acknowledge the contributions made by the authors of the following software packages.
Zebedee uses the “Blowfish” encryption algorithm devised by Bruce Schneier. For more information on Blowfish see http://www.counterpane.com/blowfish.html . The implementation used is by Eric Young and is covered by the following copyright:
Copyright (C) 1995-1997 Eric Young (eay@mincom.oz.au) All rights reserved.
This package is an Blowfish implementation written by Eric Young (eay@mincom.oz.au).
This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution.
Copyright remains Eric Young’s, and as such any Copyright notices in the code are not to be removed.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Eric Young (eay@mincom.oz.au)
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The license and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distrubution license [including the GNU Public License.]
The reason behind this being stated in this direct manner is past experience in code simply being copied and the attribution removed from it and then being distributed as part of other packages. This implementation was a non-trivial and unpaid effort.
Zebedee uses the zlib compression library by Jean-loup Gailly and Mark Adler. It is covered by the following copyright notice:
(C) 1995-1998 Jean-loup Gailly and Mark Adler
This software is provided ’as-is’, without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler jloup@gzip.org madler@alumni.caltech.edu
Zebedee may use the bzip2 compression library by Julian Seward which is covered by the following licence:
This program, "bzip2" and associated library "libbzip2", are copyright (C) 1996-1999 Julian R Seward. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. The origin of this software must not be misrepresented; you must
not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
3. Altered source versions must be plainly marked as such, and must
not be misrepresented as being the original software.
4. The name of the author may not be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Julian Seward, Cambridge, UK. jseward@acm.org bzip2/libbzip2 version 0.9.5 of 24 May 1999
By default Zebedee is built using an aribtrary precision integer arithmetic
library derived from the sources to mirrordir-0.10.49 which in turn derived
this from the Python sources. The copyright is as follows:
huge-number.c: arbitrary precision integer library from Python sources This has nothing to do with cryptography. Copyright (C) 1998 Paul Sheer
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
This file was taken from the Python source for `long’ type integers. I have changed it to compile independently of the Python source, and added the optimisation that GNU C can use 31 bit digits instead of Python’s 15 bit. You can download the original from www.python.org. This file bears little resemblance to the original though - paul
Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam, The Netherlands.
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Stichting Mathematisch Centrum or CWI or Corporation for National Research Initiatives or CNRI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.
While CWI is the initial source for this software, a modified version is made available by the Corporation for National Research Initiatives (CNRI) at the Internet address ftp://ftp.python.org.
STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM OR CNRI BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Zebedee uses the Secure Hash Algorith (SHA) the code for which was derived from Uwe Hollerbach’s SHA module for perl. The code contains the following statement:
NIST Secure Hash Algorithm heavily modified by Uwe Hollerbach <uh@alumni.caltech edu> from Peter C. Gutmann’s implementation as found in Applied Cryptography by Bruce Schneier
This code is in the public domain
Under Windows, Zebedee uses an implementation of the getopt function covered by the following copyright:
Copyright (c) 1987, 1993, 1994 The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Special thanks go to those people who have taken the trouble to give me feedback and suggestions for improvement!
$Id: zebedee.pod,v 1.19 2002/05/29 07:59:58 ndwinton Exp $