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.