by Joel R. Voss aka. Javantea
jvoss@altsci.com
jvoss@myuw.net
Jan 20, 2006
UDP Session 0.4.0d Source
[sig]
UDP Session 0.3.3c Source
[sig]
UDP Session 0.3.2b Source
[sig]
This program connects two computers without having either be a server. It uses "Evasive UDP Session Establishment" originally conceived by Winston Williams and other concurrent developers. The initial idea of the system was to poke holes in a firewall by using UDP's design as a stateless protocol. That way, both computers could consider themselves clients to a remote server. Upon further development, I found that other developers had designed similar systems with different mechanics.
Version 0.3 is encrypted with Blowfish-cbc. This 128-bit encryption is easily considered strong if used with strong passwords. Version 0.3 is statically or dynamically linked to libssl and libcrypt, so their licences apply. I will include the proper licensing agreements in future versions. Since the current version is such a fast release, it makes sense to release it sooner than later. To implement Blowfish-cbc, I created a library which wraps the OpenSSL calls in a way that is easily usable. That library is called SSL Blowfish Wrapper for the time being.
Version 0.3.3c added support for Diffie-Hellman key exchange, which is extremely cool. It removes the vulnerability of passive sniffing due to weak passwords. With Diffie-Hellman, the encryption key is strong. Password Authentication ensures that you are talking to a person with the password. It uses hashing to ensure that you don't lose important passwords by accident. The system used is: encrypt(SHA1(time+rand+password)).
Version 0.4.0a adds support for integrity checking and retry transfers, It also takes statistics on how efficiently and reliably UDP is transmitting the packets.
Version 0.4.1 will support DSA key authentication, which is good for those that rather use public key authentication instead of password authentication.
The simplest system that employs this method and works is to use Netcat.
jvoss@ASLinWs01:~$ nc -u -p 3111 dmitry.altsci.com 3222 suzy: poke dmitry: hi suzy: hello jvoss@AsBsdSv10:~$ nc -u -p 3222 suzy.altsci.com 3111 dmitry: hi suzy: hello
1) AsBsdSv10 is dmitry.altsci.com running OpenBSD with packet filtering on,
and will not allow any remote udp incoming (tested).
relevant lines of pf.conf:
block all
pass in on $ext_if inet proto udp \
from any to ($ext_if) \
port { 5050 } keep state
pass out on $ext_if proto { udp, icmp } \
all keep state
2) ASLinWs01 is suzy.altsci.com running Slackware 10.1. It has iptables off.
3) ASLinWs01 is behind a NAT router/modem (running Linux). It has iptables running, but no relevant udp blocking. Default settings for a linux modem/router.
This is not a perfect system because the first message by suzy is dropped. This
seems like it is connected with the poking of holes in the firewall. I'm not
certain whether this is true.
A better system is the Python udpchat1.py which is distributed with
udp_sess-0.1.tgz.
The code was originally written as
an example of udpchat
but it seems to use the same system of firewall avoidance.
jvoss@AsBsdSv10:~/dev/udp_sess$ python udpchat1.py suzy.altsci.com 3222 3111 chat1 on port 3222 . Blank line to quit. this is a test ('66.228.195.74', 3111) this is a reply jvoss@ASLinWs01:~/.../udp_sess$ python udpchat1.py dmitry.altsci.com 3111 3222 chat1 on port 3111 . Blank line to quit. ('207.244.153.137', 3222) this is a test this is a reply
You can see that no poking is required for this to work. This is quite likely because it uses a better system for networking. It uses a single socket and it does a bind() as normal, then instead of a connect, it does a sendto() and then recvfrom(). It seems like these two commands are a lower level of socket commands. They do not require root, so they are fair game.
Actually, looking at several example UDP implementations, I found the same system used in all. sendto() and recvfrom() are standard in UDP communication. This is because the design of UDP is stateless. A 'connection' is made so that the server binds to the UDP port and receives from any client. It then does a sendto() to that client. The client just does the same thing in the reverse order: it binds to the UDP port, initiates a sendto() to the server and then receives from the server.
Since Python isn't the perfect language for working with this, I wrote a demo in C, which is included in the udp_sess-0.1.tgz. Simply enough, it is a demo of the same code in C without threading. It needs a lot of work, but it works already. It can stream a file (at 1024 Bytes per shot) over the same connection as the other code.
One cool and useful note is that the three methods of getting this protocol to work actually interoperate pretty well. Since the C program does not work well for most stuff and the python isn't perfect either, you can use a combination of the two to satisfy your needs. For example, you could hook up the netcat version on a BSD server that doesn't have Python. You can use the Python version on a Windows server you don't have rights to compile code on. You can use the C version on a Linux workstation that you want to use as a file transfer server.
You see that the possibilities are very cool when you have interoperability. It will be my goal to develop C, Python, and Perl versions of the protocols that I develop so that as many platforms as possible are supported by this excellent protocol.
Usage: udp_sess1 [-c] [-r] [-f file] local_port remote_addr remote_port
-c : Chat only, no files.
-r : Receive file.
-f file : Read or Save file in filesystem.
The default options are to send a file from stdin.
Example: udp_sess1 3111 207.244.153.137 3222 < r.txt
udp_sess1 -f d.txt 3111 207.244.153.137 3222
udp_sess1 -r 3111 207.244.153.137 3222 > d.txt
udp_sess1 -c 3111 207.244.153.137 3222
python udpchat1.py suzy.altsci.com 3222 3111
python udpchat1.py dmitry.altsci.com 3111 3222
If you are interested in developing UDP Session Development, feel free to
e-mail me.
Back