From: Matt Blaze <mab@crypto.com>
Date: Sun, 29 Jan 95 15:58:54 PST
To: ghio@myriad.pc.cc.cmu.edu (Matthew Ghio)
Subject: Re: Telnet Acrobatics
In-Reply-To: <m0rYiZL-0006TuC@myriad.pc.cc.cmu.edu>
Message-ID: <199501300002.TAA29052@crypto.com>
MIME-Version: 1.0
Content-Type: text/plain



>What follows are two small programs which I thought might be of interest to
>cypherpunks.  The first (socket.c) is a simple daemon which binds a port
>and accepts connections, and then forks child processes for each one.
>The second (relay.c) is a simple telnet program which opens a connection to
>the specified remote host and port number.  Put together they can be used
>as a telnet relay ("proxy server") that works like the term redir command.
>This in itself is useful, if you want to hide where you're coming in from,
>bypass a broken router or get through a firewall.  But, take a look at the
>loop at the end of the second program.  It simply reads input from one
>socket and writes it to another.  It would seem to me very easy to add
>an encryptor/decryptor to this process and encrypt your telnet sessions.
>You'd just need to exchange a key (via PGP) with the remote system, and
>decide on a port number, then run crypt/dec daemons on both systems.  The
>socket.c program might also be useful for socket-based remailing.  (Tho
>you can set it up in your inetd.conf instead, if you have root access.)

...

This is really funny - these programs are almost *exactly* the first
assignment in the computer networks class that I taught at Columbia last
Spring.  I think these may actually be modified versions of one of the
submissions from one of the students in the course.  (The actual assignment
called for something slightly different from these two programs, but close
enough to make it easy enough to modify.  Assignment sheet attached below
for reference...)

By the way, speaking of encrypted sessions, I'm currently shaking the
bugs out of "esp", an application-level encrypted session manager for Unix
terminal sessions across untrusted networks.  It's based on RSAREF
and 3-DES, and I expect to release it next week or so.  Stay tuned.

-matt

========== assignment1.ms (troff -ms format) attached below ===============
.nr FM 1i
.nr HM .75i
.nr LL 6.9i
.nr PO .85i
.OH ""
.EH ""
.TL
Homework #1: TCP Laundry Service
.AU
CS 4119 - Computer Networks
.AI
Assigned: Thursday, January 27, 1994
Due: Sunday, February 13, 1994, Midnight
.NH
The Problem
.PP
One of the features of the TCP/IP protocol suite is that two communicating
entities each need to know the network address of the other.  In general,
this is a useful property; it makes it possible, for example, for a server
to use the network address of clients who connects to it as part of an
authentication protocol.  An example of this is the
.I rlogin
protocol, in which the server machine uses the network address from which
a request originates to determine whether to ask for a password before letting
the user log in.  (It is worth understanding how this works, by the way,
and the inherent risks of relying on the network for authentication).
.PP
Sometimes, however, it is desirable to offer completely
.I anonymous
services in which the server has no way to determine where a connection to
it originates.  For example, it may be useful to provide the ability for
informants to send anonymous electronic mail to news reporters or law
enforcement agencies.
.PP
Unfortunately, the Internet Protocol (IP) suite does not provide for
anonymous communication.  One way to simulate anonymous communication is
to make use of intermediate "data laundry" servers, whose sole purpose is
to relay traffic between its sources and destinations.  Data laundries derive
their name from the criminal practice of "money laundering", where a
criminal moves his or her loot between several businesses and banks in an
effort to obscure the connection between stealing the money and spending it.
A data laundry accepts connections from clients (or other
laundries) and connects them to whatever remote service (or laundry) they
wish to communicate with.  Since the final destination thinks it is
communicating with the laundry, the only way to determine the real origin
of a connection would be to compromise the security of each of the laundries
along the way.
.NH
The Assignment
.PP
Your job is to build a laundry service for TCP connections.  This should
consist of two parts: a
.I "laundry daemon"
which connects clients to services and a
.I "laundry client"
which provides a convenient front end to users of the service.
Also write a short manual describing how to use your programs.
.NH 2
Laundry Daemon
.PP
The laundry daemon should accept TCP connections on a pre-selected port
number (pick one that isn't already used by some existing service).  When
a connection comes in, it should \fCfork\fP a subprocess for the duration
of the connection and print a message announcing that it is ready:
.DS
\fC100 cs.columbia.edu laundry service ready\fP
.DE
All messages from the daemon should consist of single lines of ASCII text
starting with a three digit number and followed by an informational message.
Messages numbers starting with 1 indicate success, message numbers starting
with 2 indicate failure.
.PP
Once the initial ready message is transmitted to the client, the server should
accept a single line of text containing a destination hostname followed by
at least one space followed by a port identifier.  Both the hostname and
port ID should be able to be specified by either their official names
or by their decimal values; you may assume that any identifier starting with a
digit is a numeric, otherwise it is a name.  Examples of valid input:
.DS
\fCcunix.cc.columbia.edu finger
128.59.40.11    79
128.59.40.11   telnet\fP
.DE
The server should then attempt to open a TCP connection to the given
host/port.  If the connection fails for any reason (host unreachable,
name lookup failure, etc.), the server should send an appropriate error
message to the client, e.g,:
.DS
\fC201 cunix.cc.columbia.edu connection refused on port finger\fP
.DE
Otherwise, the server should send a message indicating success:
.DS
\fC101 connected to cunix.cc.columbia.edu port finger\fP
.DE
.PP
Once the connection is established, the daemon should simply relay 
the all traffic between the source and destination.  If an error occurs
or the connection to either side of the connection closes, the daemon
should close both sides of the connection and terminate the subprocess.
.PP
Your laundry daemon should be able to handle arbitrarily many connections
simultaneously.  In particular, it should be possible to launder connections
through itself.
.NH 2
Laundry Client
.PP
The laundry client provides a convenient front end to users of the laundry
service.  Its job is to read, from a configuration file, a list of
laundry servers (and the TCP port numbers they run on) followed by
a final destination and port number.  For example:
.DS
\fCa.columbia.edu 10000
b.columbia.edu.edu 10000
cunix.cc.columbia.edu telnet\fP
.DE
would launder a TCP connection to the telnet port of cunix.cc.columbia.edu
through laundry servers running on port 10000 of a.columbia.edu and
b.columbia.edu.
.PP
Once the connection is established, the laundry client should simply connect
its standard input and standard output to the laundered connection.  Upon
EOF at either the remote connection or the standard input, the client
should close the connection and terminate.
.PP
If the connection fails any any point along the laundered path,
the client should print an appropriate error message and terminate.
.NH
Hints
.PP
You'll need to be familiar with the system calls for establishing TCP
connections (socket, connect, bind, etc.), the routines for looking up
host and service names (gethostbyname, etc.), the system calls for
manipulating terminal IO (ioctl), and the system call for multiplexing
input streams (select).
.PP
A common source of errors is to try to bind your service to a port already
in use by another process.  Make sure the port number you're using is
not already in use.  Also, make sure you kill any laundry daemons you've
started when you're done testing your program.
.NH
Extra Credit Ideas
.PP
Make the laundry service fully compatible with the telnet protocol.
.PP
Extend your service to provide encrypted connections. (You'll want to
learn about key exchange protocols.  You'll find the RSAREF library,
available at the rsa.com ftp site, helpful.)
.PP
Extend the laundry service to allow laundered servers as well as clients;
that is, allow a service to set up and accept connections through a chain
of proxy servers.
.PP
For lots of extra credit, make your code available and convince lots of
people to adopt it as a standard.  (This is more work than it's worth!).
.NH
Policy
.PP
Your program will be graded based on whether it works according to the
assignment, how well it handles errors, and the quality of your
documentation and code.
Turn your programs in with the submit program; your TAs will have information
on how to use this.
Late programs will be accepted, but with a reduced grade.  Late programs
cannot get extra credit.