http:// www.jms1.net / ucspi-tcp /

ucspi-tcp Information

UCSPI is the Unix Client Server Program Interface, a set of command-line tools which handle the client and server interfaces of a given protocol. UCSPI was developed by Dan Bernstein, who also developed qmail and djbdns. ucspi-tcp is djb's implementation of UCSPI, using the TCP protocol. It consists of two primary programs, tcpclient and tcpserver.

tcpserver can be thought of as a "replacement" for inetd, the "Internet Super-server" found on most *nix systems. However, there are a number of differences:

tcpserver only handles one service at a time. If you wish to run multiple services under tcpserver, you run multiple copies of tcpserver.

tcpserver is not vulnerable to the connection-flooding issue which can cause inetd to stop answering any connections (on ANY services, not just the one being attacked) for five minutes at a time.

tcpserver has a very flexible access control mechanism based on IP addresses. It can accept or deny connections to any IP or block of IPs, and if the connection is accepted it can optionally set environment variables which are visible to the actual service program.

tcpserver can block access based on the remote IP being listed in an RBL (realtime blacklist.) This is useful for mail servers, when you don't want to accept mail from known spammer IP addresses.

I have been using tcpserver in conjunction with my mail server for several years, and have recently started using it to develop custom services for my clients as well.

Patches

I have fond a few patches to be useful over the years. The patches I am using are:

ucspi-tcp-0.88-errno.patch fixes the issue with "errno" which started happening with the release of glibc 2.3 and their thread-safe errno implementation.

ucspi-rss.diff (from qmail.org) causes the rblsmtpd program (which holds SMTP connections from RBL-listed IP addresses in a "jail" of sorts, rather than making the real qmail-smtpd waste time on them) to look for A records instead of TXT records when testing to see if a given IP address is or is not listed in an RBL. The first RBLs used TXT records, but because the zone files were getting to be too big to manage, the RBL maintainers switched over to just using the existence or non-existence of a given A record as the indicator.

ucspi-tcp-ssl-20020705.patch (from www.nrg4u.com) gives tcpserver the ability to handle SSL connections directly.

ucspi-tcp-0.88-periplimit.6.patch (from this page) gives tcpserver the ability to limit how many simultaneous incoming connections can come from any one IP address. This is useful if you have a spammer who wants to open twenty connections to your server at once (I've seen it happen- only a few times, but it does happen every once in a while.)
However, there are some problems.
First, this patch doesn't apply cleanly after the ssl patch has been applied. I expected this to happen at some point, and was able to manually make the changes for the two "chunks" which failed (one in Makefile, one in tcpserver.c.) Nothing major, this is what the game of combining patches is all about.
However, the big problem is that the ssl patch and the periplimit patch both want to add a "-s" option to tcpserver. The SSL patch wants to use it to turn on SSL support, and the periplimit patch wants to use it to to indicate the number of connections which are allowed from any single IP address. Obviously this is a major conflict.
To get around this problem, I have modified the periplimit patch to use "-i" instead of "-s". I have emailed the maintainer of the periplimit patch with a description of my changes (which consist of changing "s" to "i" in four places, all in the same file.) I would imagine the change will eventually be added to a future version of his patch- it would mean a change for the existing users of his patch, but if they wish to combine it with the SSL patch it will be necessary. I would be rather surprised to find that I am the only person in the world to ever need to combine his periplimit patch with the ssl patch...

ucspi-tcp-0.88-rss-ssl20020705-periplimit6.patch is a single patch file which combines all of the patches listed above, along with the modifications for the per-IP limit command-line option.

After applying the patches and making the manual change described above, I had to make one other manual change to make the package compile on WhiteBox Enterprise Linux (which I'm running on my server.) I had to add this line to the beginning of Makefile:

INCS=-I/usr/kerberos/include
Apparently WhiteBox distributes their openssl libraries with links into the kerberos libraries, which means any programs using the openssl libraries also need to include the kerberos headers as well. I remember this being the case with RedHat 8.0 and 9, and because WhiteBox is a re-packaging of RedHat Enterprise, I would strongly suspect that the same will be true for RedHat Enterprise as well.

ucspi-tcp-0.88-rss-ssl20020705-periplimit6-krb.patch is the same combined patch file, along with the Makefile change needed in order to compile on systems where openssl is linked with kerberos.

2004-07-05 There seems to be an issue with the patch set above. I've been using it for my SMTP-SSL server for most of today. It seems that it "doesn't like" certain email messages- any message that I try to send to one of my clients, for example, is hanging up in the middle of the SMTP conversation.

This also happened last night with an email to the maintainer of the periplimit patch, but when I changed "Balácz" to "Balacz" it worked without a problem- so I figured it probably had something to do with perl's unicode handling (I'm using qmail-scanner, which is written in perl.)

Except that the same message worked when I switched back to my stunnel based SSL service, and the emails to this client today are also working when I send them through the stunnel server.

From doing some manual testing (using "openssl s_client -crlf -connect server:port") it looks like the server is trying to re-key the SSL layer halfway through the conversation, and the openssl client is terminating when it happens. The server then drops the socket with an error saying "tcpserver: warning: dropping connection, unable to accept SSL connection".

The same command pointed to the stunnel server does almost the same thing- it re-keys the connection, always immediately after entering the RCPT TO: command (the same place where the SSL-in-tcpserver version re-keys, which I don't understand- how does qmail-smtpd have anything to do with re-keying the SSL connection? It doesn't know or care that SSL is happening) but the openssl client does NOT crash, although the RCPT TO: command itself never seems to make it to qmail-smtpd... I am able to issue other SMTP commands and get the proper responses (i.e. the qmail home page in response to HELP, or "503 RCPT first" in response to DATA) but the RCPT TO: command itself never seems to have any effect- it wants to re-key the connection instead. Strange.

I'm open to suggestions, if anybody out there has any idea what's going on here...

2005-03-29 Thanks to an email from a reader (I guess people do actually read this page, how about that?) I have taken another look at the issue. It turns out that the SSL re-keying was being caused by the openssl s_client command itself- when it sees a line starting with a capital "R", it re-keys the SSL layer on its own. Handy feature, but there needs to be a way to either disable this feature, or at least change what character triggers it.

Word to the wise- when using openssl s_client, make sure you don't need to type anything with a capital "R" as the first character of a line (such as "RCPT TO:" when testing a mail server.) Also don't type anything with a capital "Q" as the first letter, this will cause openssl s_client to drop the connection immediately.

And I'm going to play with this stuff again right now, since it's fresh in my mind again. Hopefully I'll have something more to report in an hour or two...

2004-03-30 After playing with it for a while, I remember now what the original problem was. When Apple's Mail.app is sending a message which is more than a few lines of text to qmail-smtpd running under tcpserver patched with the full patch above, it gets about thirty lines into the body of the message and then hangs for about five minutes before finally timing out. Short messages seem to work okay, but longer messages hang up in the middle.

Running with recordio shows that the message is being sent normally until a certain point, but then it just stops. No error messages, nothing to indicate any problem... but the data stops coming in.

Either the server is waiting for the client to send more data, or the client is waiting for the server to acknowledge the data which has already been sent. I'm not sure which, but I suspect the problem is with one of the patches on the server end. I can't really use my live server for testing, at least not for more than a few minutes... so for now I've gone back to using stunnel for my SSL-secured SMTP server.

However, this "hang" only seems to be an issue when SSL is involved- normal tcpserver-based services seem to work normally, so I am sticking with the fully patched version for now (since SMTP-SSL is currently the only service I'm using this for.) I will be looking for updated versions of these patches. Watch this space for further news...

2005-03-30 Google has led me to another package called ucspi-ssl. I am currently testing this as a replacement for tcpserver when setting up SSL-secured services... I'm testing it with my SSL-SMTP server, and so far it seems to be working fairly well. If you're also using my qmail scripts and want to try this for your SSL-SMTP server, this link is a copy of the "run" script I'm using to start the server.

Of course this other package doesn't have a way to limit the number of connections from any one client IP address... this isn't as big an issue for me as it once was, I am finding that I can live without this particular patch. However, at some point in the future I may take the patch for ucspi-tcp and port it to ucspi-ssl... if I can make it work I will send it to the developer of ucspi-ssl for inclusion in a future version of the package.