|
DISCLAIMER!
As much as I would
like to take responsibility for everything you do, I'm afraid that I
just can't. Proceed at your own risk! To the best of my knowledge, the
information contained herein is accurate. However, if there is bad information
and wicked things happen to your system, you're on your own. Whenever
you start messing with things, there's a chance you'll muck things up.
If you think you might muck things up, don't mess with your computer.
Leave well enough alone! If you can't stand the way your system is running,
and you want to proceed anyhow, consider yourself warned!
(updated 03/19/2002)
WHO?
This is a quick, no-frills document for anyone who is interested in
step-by-step instructions on setting up an IMAP
server with SSL support on Linux.
If you want to learn more about IMAP, SSL, or Linux, keep searching.
WHAT?
This document is
a quick step-by-step howto on setting up your own University
of Washington (UW) imapd server with SSL support and generating
your own x.509 certificate.
Even though the directions below can be easily adapted to setup POP3
over SSL, it is something that I refuse to cover. IMAP stands for Internet
Message Access Protocol, and is the replacement protocol for POP3. You
can read more about IMAP at http://www.imap.org.
You may also wonder why I chose UW's imapd over Cyrus's imapd server.
Personally, I think that Cyrus's imapd is a pain in the arse to setup
and configure. If you wish to write your own Cyrus imapd with SSL howto,
I'll be more than glad to give you a link.
WHY?
By adding SSL support to your IMAP server and using a SSL enabled email
client, you can increase the security of your email communications and
passwords (between your machine and the mail server). Think about how
many times you check email a day. That's how many times your email username
and password is sent in the open.
Email is one of the
most important services on the Internet. Unfortunately, it is also one of
the least private/secure forms of communication on the Internet. Most email
applications not only transfer messages in plain-text, it also sends usernames
and passwords in plain-text This not only leads to the loss of privacy,
but creates a huge security risk by making usernames and passwords available
to anyone with access to a sniffer at the right place. Most mail admins
don't bother with using authentication schemes such as APOP,
Kerberos,
NTLM, CRAM-MD5,
etc. usually because of the lack of email-client support and user support
issues.
In addition, even if
the authentication is secured, the contents of your messages are still vulnerable.
While a relatively few select individuals use encryption such as PGP
(Pretty Good Privacy) or GPG (GNU Privacy
Guard), the bulk of email users (will) never bother with such cumbersome
technology. Fortunately,
people are already working on this problem. By adding SSL support to mail
servers and clients, the communication (including login info) between the
mail server and the email client is (transparently) made private by the
use of encryption.
However, please note
that scope of this document only covers how to secure the "downward"
communication channel between the mail server and the email client. The
"upward" communication channel (SMTP) is still unsecured. The
communication between mail servers is also still carried out in plain-text
There is also work under way to add encryption
support to mail servers (see RFC2487).
Perhaps this'll be the subject of another howto.
WHERE?
The absolute newest
version of this HOWTO can always be found at http://www.knowplace.org/imaps.html.
Prerequisites:
~Optional:
HOW?
First, a quick overview.
If you don't already have OpenSSL installed, you will need to first
download, compile and install it (and generate a certificate). Once
that's installed, you can download, compile, and install UW's imapd.
Once that's installed, you will need to modify your /etc/inetd.conf
and restart your inetd. Depending on the speed of your system, compiling
will probably the most time consuming part of this process. The actual
setup time takes only a couple of minutes if that.
- Installing
OpenSSL:
- After you've
downloaded the openssl-0.9.6.tar.gz tarball, extract to to a temporary
directory (e.g. tar xzvf openssl-0.9.6.tar.gz).
This will create a directory called openssl-0.9.6/
inside your current working directory.
- Execute cd
openssl-0.9.6; ./config
&& make (use
./config threads instead if you have
a SMP system) to automatically configure the Makefile (read the INSTALL
file yourself if you feel like getting fancy) and start compiling
(take a break, this'll take a while).
- Execute make
test to make sure everything is working correctly. If it passes
all of the tests, make install (if you
didn't change anything, this will install OpenSSL into /usr/local/ssl).
- Creating
server certificates:
- You can now create
a server certificate for your mail server (note: certificates by themselves
won't do anything until your new imapd is installed). To create a
certificate, execute cd /usr/local/ssl/certs/;
openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days
365. Note:
This command creates a self signed certificate that expires in exactly
one year (strictly speaking, the -days 365
switch isn't necessary; if you omit it, the certificate defaults to
expire in 365 days.).
- You'll be prompted
for Country Name (2 letter code), State
or Province Name (full name), Locality
Name (eg, city), Organization Name (eg,
company), Organizational Unit Name (eg,
section), Common Name (eg, YOUR name),
and Email Address.
- Pay
special attention to what you enter as the Common Name.
Since this is not a personal certificate, but the certificate of your
IMAP server, it needs to be the DNS name or IP address of your mail
server (e.g. mail.knowplace.org).
- If you do not
enter the correct DNS name (or IP address), you will get errors similar
to "The server you are connected to is
using a security certificate that does not match its Internet address.
Do you want to continue using this server?" While this
is not a fatal error, it is annoying. =)
- If your mail
server is multihomed (multiple interfaces), or has multiple domain
names, you can create additional certificates by executing openssl
req -new -x509 -nodes -out imapd-x.x.x.x.pem -keyout imapd-x.x.x.x.pem
-days 365 (where x.x.x.x is the IP address of the interface).
When prompted for the Common Name, enter the corresponding name (or
IP address) for that interface. Note:
Whatever you enter as the Common Name will be the server name that
you enter in your email clients. I tried creating certificates in
the form of DNS names instead of IP addresses, but it would not work
for me (e.g. openssl req -new -x509 -nodes -out
imapd-mail.knowplace.org.pem -keyout imapd-mail.knowplace.org.pem
-days 365). If you figure it out, please send me an email.
- Installing
UW imapd:
This section covers the compilation for Linux systems with PAM (most current
distributions). If you are using a distribution that uses RPM's, you can
execute rpm -qi pam to see
if you have PAM installed. Since this is the norm, I will not cover how
to install PAM in this document.
- After the download
has completed, extract the files into a temp directory by executing
tar xzvf imap.tar.Z. This will create
a directory called imap-2001.BETA.SNAP-date_of_the_snapshot
inside your current working directory.
- Execute CD
imap-2001.BETA.SNAP-date_of_the_snapshot; make lnp PASSWDTYPE=pam
SSLTYPE=unix to compile your new imapd.
- Once the compile
finishes, copy your new imapd to a suitable directory such as /usr/sbin/imapd
by cp -p imapd/imapd /usr/sbin (if you
have another imapd that's in the same location, you might want to
consider backing it up first).
- One other note
about security. With your new imapd server installed (even with SSL
support), it's a good idea to configure it to use CRAM-MD5 passwords.
UW's imapd can use a separate password database (/etc/cram-md5.pwd)
to do user authentication. This makes it possible to keep use separate
login/mail passwords.
- If this file
is missing on your system, simply create it by touch
/etc/cram-md5; chmod 0600 /etc/cram-md5. Since the
passwords are kept in plain-text, it's important to make sure
that no one else has permissions to read/write this file.
- The syntax
format of this file is <username><tab><password>
(without the <>'s) and lines beginning with # are comments.
Do yourself a favor and don't
pick a password like 'secret'.
- The only thing
left to do now is to add the imaps service to your inetd. Edit your
/etc/inetd.conf file and add the line imaps
stream tcp nowait root /usr/sbin/imapd imapd. Note:
Do not use tcpwrapper for this service. It will not work correctly
if you do.
- Restart your
inetd daemon by executing kill -SIGHUP `cat
/var/run/inetd.pid` && /usr/sbin/inetd. On SuSE,
you can do /etc/rc.d/inetd stop &&
/etc/rc.d/inetd start.
- Some
last comments:
- Don't forget
to allow port 993 to your imap server on your firewall. If you're
behind a firewall that drops packets to identd (tcp port - 113), you
might notice considerable delays while connecting. If you reject all
requests on your firewall to 113, instead of dropping it, this will
considerably shorten connection times (also helps with things like
FTP or SMTP). The other solution is to setup a fake
identd if you're paranoid about information leakage.
- If you no longer
need to support plain-text imap on your server, disable port 143 (and
comment out imap stream tcp nowait root /usr/sbin/tcpd
imapd). Less is more. Comment out POP3 while you're at it.
- You might want
to consider using xinetd instead.
Even though inetd with tcpwrapper has come a long way, xinetd still
has superior logging capabilities. In particular, I find the log_on_success
= DURATION (/etc/xinetd.conf) to be particularly useful for
monitoring the duration of connections.
- Some IMAP with
SSL enabled email clients are Mulberry
(works some what - crashes often) Netscape
Messenger (surprisingly good), Microsoft
Outlook 2000/Outlook
Express (avoid if you can - but the best GUI), and Eudora
5.1 (beta). Latest versions of Mutt
and Pine also supports
SSL. If you know of others, please send me an email. I've tested Mulberry
and Outlook Express so far, and both seem to work fine. The Eudora
5.1 beta would not work for me.
- If you generated
your own certificate, Outlook Express 5.5 and above will complain,
"The server you are connect to is using
a security certificate that could not be verified. 0x800b0109 Do
you want to continue using this server?" To install your
custom certificate, type the URL https://your.mail.server:993/
into Internet Explorer. See http://www.seifried.org/security/best-practices/ksbpa-001-ssl_imap_pop_linux.html
for details.
- For Eudora users,
if you get a "<Dominant>, Logging
into POP Server, SSL Negotiation Failed: Certificate Error. Cert Chain
not trusted. Try adding this certificate to your certificate database
for SSL to succeed Certificate Error.", see http://www.eudora.com/techsupport/kb/2323hq.html
for a work around.
- I'm assuming
you've already disabled telnet access to your machine and installed
OpenSSH. There's no point disabling
plain-text logins for email and allow plain-text telnet sessions.
- Just because
you generated your own (self-signed) certificate, this doesn't mean
that it's any less secure than a certificate that you can purchase.
I'd recommend that you read Ten Risks of PKI: What You're Not Being
Told About Public Key Infrastructure by C. Ellison and B. Schneier
- http://www.counterpane.com/pki-risks.html
before spending money on a certificate (unless it's not your money).
Simply stated, certificates allow you to do encryption. While the
use of encryption may help you improve security/privacy, the security
of your system depends on many more complicated variables. The weakest
link is usually the user/admin.
- A couple of days
after this document was initially writen, Microsoft issued a security
warning about a couple of erroneously issued Verisign certificates
(http://www.microsoft.com/technet/security/bulletin/MS01-017.asp).
This only serves to stress the point above.
Go away already...
Find a hobby...
Goto
page top
Created and maintained
by Shane Chen (shane@knowplace.org)
Copyright © 1996-2001. knowplace.org.
|
