Computer Services

Computer Services
Stanton/Wilmington Campus
Trying to Hack SSL into Certain Services

This document explains how I got SSL and stunnel to wrap certain daemons. It was written "as I went along" and reflects a certain kind of chaos as the result of it. I could have cleaned it up, but I certainly remember feeling like I was an idiot for not getting all of this the first time around. Therefore, I leave my "discovery" process documented here along with later corrections in an attempt to help others who stumble upon these pages.

My First Attempt, UW imapd

(This portion originally written circa early 1998)

Plain text passwords are a really bad idea. Easy to say, but difficult to get rid of. We've dumped plain text logins on file sharing and now support SSH telnet logins, but more and more people want to use a GUI to read e-mail -- and that means supporting POP3 or IMAP.

Netscape supports SSL between client and server, but our IMAP server software does not. At least not out of the box. Using SSLeay and stunnel, it's possible to graft SSL support onto UW IMAP (or other inetd servers).

This documents one way to do it, from the viewpoint of someone who just started reading about SSL a few days ago. (If you are lurking and notice any glaring problems, please let me know).

This is intended as an internal document only. No outside support is implied, but if I can answer a question off the top of my head, I'll do my best.

Notice

A lot of this stuff comes with really ugly and confusing restrictions, including U.S. export and import restrictions due to patents and crypto regs. Be sure to read associated docs and licenses.

Reference web sites

Overview

Netscape is an SSL client. It connects to an SSL enabled imap server. Only catch is, UW IMAP server does not support SSL. Enter Stunnel. Stunnel establishes the SSL pipe over the net, then communicates to the designated server in cleartext through the loopback interface. Read stunnel man page above for more info.

So, basically the following macro steps (detailed further below) are needed:

  1. Install SSLeay
  2. Install stunnel
  3. Create server keys and certificates
  4. Make mods to inetd.conf to wrap desired daemons.

Installation Steps

NOTE:This pertains to the current rev of stunnel when I did this, which was 1.6. Some bits have changed a bit, see notes further down for further details.

For a newbie, I got lost quickly and spent days on and off trying to get this to work. Read through the steps below and try and follow the path I took. I don't think you *need* to create a certificate authority at all, just to do secure SSL imap. Just create a dummy certificate (step with "strong" text below) and away you should go. However, I'm keeping the stuff below for doing a certificate, cause it worked and may get used later to allow us to issue certificates for students to encrypt their e-mail.

In other words, you probably don't have to generate a certificate authority and the rest of that nonsense and just do the "dummy certificate" part. But there may be some minor step in there critical to the process, and I don't feel like running it all through again to make sure right now. (Hey, it's 04:00 am and I've been up all night!)

  1. Obtain and install SSLeay sources (referenced above). (reference version 0.8.1) Be sure to read docs, licensing, and notes about linking in RSAREF if in the U.S. Then:
    1. ./Configure dgux-R4-gcc (or appropriate for your box)
    2. make
    3. make test
    4. make install
    5. edit /usr/local/ssl/lib/ssleay.cnf to taste. For example, change the defaults. First step, get rid of AU as the default country! :) Also change the dir default directory (like to /usr/local/ssl)
  2. Grab stunnel sources from above and install (reference version 1.6):
    1. Run ./configure. Sets up stuff for DG/UX just fine.
    2. make
    3. Copy to /usr/sbin or appropriate and edit inetd.conf and /etc/services as explained in the stunnel man page.
    4. Don't forget to send a SIGHUP to identd process to read conf file
    5. Installing service doesn't affect existing imapd service since it listens on a different (993) port.
  3. Create support files and directories
    1. cd /usr/local/ssl (or appropriate)
    2. touch index.txt
    3. echo "01" > serial
    4. mkdir newcerts
    5. Generate some random data into rand.dat (example: who -a > rand.dat)
  4. Generate a private key with passphrase and then a certificate authority. If you just want to make a dummy certificate for ssl imap, then don't worry about the below steps. I'm not so sure about them myself but damn it, I wrote it down, so I don't want to delete it!
    1. bin/ssleay genrsa -rand rand.dat -des3 1024 > private/cakey.pem
    2. ??? bin/req -new -x509 -key private/cakey.pem -out cacert.pem -days 999
      (Is this step really needed?)
    3. bin/req -new -keyout newreq.pem -out newreq.pem -days 999
    4. bin/ca -policy policy_anything -out cacert.pem -infiles newreq.pem
  5. Change Apache web server to allow users to import CA data. Do this by adding the below line to srm.conf file:
    AddType application/x-x509-ca-cert cacert
  6. Copy cacert.pem to somefile.cacert in htdocs directory, make public and a link to it from somewhere (with suitable explanation)
  7. Generate a "dummy certificate" for imapd service
    1. cd /usr/local/ssl/certs
    2. ../bin/req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 999
      Warning: Be sure to use the host name of the machine in the Common Name field. If you don't, you'll get a certificate error from Outlook (and probably other clients) when connecting
    3. ln -s imapd.pem `/usr/local/ssl/bin/x509 -noout -hash < imapd.pem`.0

Neat stuff to look at for future fun

Updates and Feedback

Using stunnel to add SSL to Apache web server

Why does this seem to be a horrible kludge?! Apache has numerous ways to add SSL support to it, yet beings that I already had stunnel working, I just had to try it out on our web server. What do you know, it works like a champ!

To get it to work, all I did was use the -r option in the new (3.0) stunnel so as to redirect the unencrypted channel over the loopback address. I also had to generate a separate certificate since our web server is www.dtcc.edu even though it (currently) sits on hopi.dtcc.edu (which is what I gen'ed the stunnel.pem cert for). All I had to do was go into my existing ssl/certs directory and do the below command: 

cd /usr/local/ssl/certs
../bin/req -new -x509 -nodes -out https.pem -keyout https.pem -days 999
Ensure that you enter the DNS name of the server in the "common name" part of the questions that req asks.

Then add the below to inetd.conf: 

https   stream  tcp     nowait  root    /usr/sbin/stunnel  httpd -p /local/ssl/certs/https.pem -r 80
Bingo, now any web page on the server can work with https://

There are some "gotchas" though. Browsers will make the user verify the self-signed certificate, pages with absolute paths in IMG tags will not work correctly since many browsers won't mix-and-match secure and unsecure stuff in a page. This is also very inefficient since two daemons now run for a https connection, not one. It also means two forks for every connect. If that's not enough, a script can't tell if it was called via https or http. Best I can see is to check REMOTE_HOST for 127.0.0.1.

In all, it's probably best to go with ssl-apache or mod_ssl but it may turn out useful for other stuff (like the swat daemon in samba).

Swat (samba admin program)

Wow, what an unexpected benefit of stunnel. When I first heard about swat (a web tool for administering a samba server), I shouted for joy. Then I found it requires authentication using the root password (which would go over the net in the clear unless you are on the same host over the loopback address).

Enter stunnel! Piece of cake. Follow the instructions in the swat docs, then add the stunnel magic to inetd instead of what's in the docs. Example: 

swat   stream  tcp   nowait  root    /usr/sbin/stunnel  swat -l /local/samba/bin/swat

General stunnel debugging tips

Last page update: 06 March 1999
Official URL for this page: http://www.stanton.dtcc.edu/stanton/cs/admin/notes/ssl/
Page Maintained by: Ken Weaverling