Recipe 8.9 Running a POPIMAP Mail Server with SSL

Recipe 8.9 Running a POP/IMAP Mail Server with SSL

8.9.1 Problem

You want to allow secure, remote mail access that protects passwords and prevents session eavesdropping or tampering.

8.9.2 Solution

Use imapd with SSL. Out of the box, imapd can negotiate SSL protection on mail sessions via the STARTTLS (IMAP) and STLS (POP) mechanisms. (See SSL for Securing Mail.) Simply set your client to require SSL on the same port as the normal protocol (143 for IMAP, 110 for POP), and verify that it works. If so, you're done.

Otherwise, if your client insists on using alternate ports, it is probably using the older convention of connecting to those ports with SSL first. In that case, use the following recipe:

1. Enable the IMAP daemon within xinetd:

   /etc/xinetd.d/imaps: service imaps {         ...         disabled = no }

   or within inetd (add or uncomment the line below):

   /etc/inetd.conf: imaps  stream  tcp     nowait  root    /usr/sbin/tcpd  imapd

   whichever your system supports.

2. Signal xinetd or inetd, whichever the case may be, to re-read its configuration and therefore begin accepting imapd connections. [Recipe 3.3][Recipe 3.4]

3. Test the SSL connection locally on the mail server, port 993: [Recipe 8.10]

   $ openssl s_client -quiet -connect localhost:993

   (Type 0 LOGOUT to end the test.)

Alternatively, use POP with SSL, following an analogous procedure:

1. Enable the POP daemon within xinetd :

   /etc/xinetd.d/pop3s: service pop3s {         ...         disabled = no }

   or inetd (add or uncomment the line below):

   /etc/inetd.conf: pop3s  stream  tcp     nowait  root    /usr/sbin/tcpd  ipop3d

   whichever your system supports.

2. Signal xinetd or inetd, whichever the case may be, to reread its configuration and therefore begin accepting ipop3d connections. [Recipe 3.3][Recipe 3.4]

3. Test the SSL connection locally on the mail server, port 995: [Recipe 8.10]

   $ openssl s_client -quiet -connect localhost:995

   (Type QUIT to end the test.)

Table 8-1. Authentication and session protection are independent

	Strong session protection	Weak session protection
Strong authentication	Protects all	Protects password, but session is still vulnerable to eavesdropping, corruption, hijacking, server spoofing, or man-in-the-middle attack
Weak authentication	Protects all	No protection: avoid this combination

8.9.3 Discussion

Many mail clients can run POP or IMAP over SSL to protect email sessions from eavesdropping or attack. [Recipe 8.11][Recipe 8.12][Recipe 8.13] In particular they protect your mail server passwords, which may otherwise be transmitted over the network unencrypted. Red Hat 8.0 and SuSE 8.0 come preconfigured with SSL support in the POP/IMAP server, /usr/sbin/imapd.

First, enable imapd within xinetd or inetd as shown, then signal the server to re-read its configuration. Examine /var/log/messages to verify that the daemon reconfigured correctly, and then test the connection using the openssl command. [Recipe 8.10] A successful connection will look like this:

$ openssl s_client -quiet -connect localhost:993 depth=0 /C=--/ST=SomeState/L=SomeCity/... verify error:num=18:self signed certificate verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/... verify return:1 * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN] localhost ...

The first few lines indicate a problem verifying the server's SSL certificate, discussed later. The last line is the initial IMAP protocol statement from the server. Type 0 LOGOUT or just Ctrl-C to disconnect from the server.

Next, test the connection from your mail client, following its documentation for connecting to a mail server over SSL. This is usually an option when specifying the mail server, or sometimes in a separate configuration section or GUI panel for "advanced" settings, labeled "secure connection" or "Use SSL." Use any existing user account on the server for authentication; by default, imapd uses the same PAM-based password authentication scheme as most other services like Telnet and SSH. (We discuss PAM in Chapter 4.)

Examine /var/log/debug for information on your test; a successful connection would produce entries like this:

Mar  3 00:28:38 server xinetd[844]: START: imaps pid=2061 from=10.1.1.5 Mar  3 00:28:38 server imapd[2061]: imaps SSL service init from 10.1.1.5 Mar  3 00:28:43 server imapd[2061]: Login user=res host=client [10.1.1.5] Mar  3 00:28:54 server imapd[2061]: Logout user=res host=client [10.1.1.5] Mar  3 00:28:54 server xinetd[844]: EXIT: imaps pid=2061 duration=16(sec)

If you don't see the expected entries, be sure that the system logger is configured to send debug priority messages to this file. [Recipe 9.27]

You might see warning messages that imapd is unable to verify the server's SSL certificate; for testing purposes you may ignore these, but for production systems beware! Some Linux systems have dummy keypairs and corresponding certificates installed for use by imapd and pop3d; for instance, Red Hat 8.0 has /usr/share/ssl/certs/imapd.pem and /usr/share/ssl/certs/ipop3d.pem, respectively. This setup is fine for testing, but do not use these certificates for a production system. These keys are distributed with every Red Hat system: they are public knowledge. If you deploy a service using default, dummy keys, you are vulnerable to a man-in-the-middle (MITM) attack, in which the attacker impersonates your system using the well-known dummy private keys. Furthermore, the name in the certificate does not match your server's hostname, and the certificate is not issued by a recognized Certifying Authority; both of these conditions will be flagged as warnings by your mail client. [Recipe 4.4]

To preserve the server authentication and MITM resistance features of SSL, generate a new key for your mail server, and obtain an appropriate certificate binding the key to your server's name. [Recipe 4.7][Recipe 4.8]

You can control how imapd performs password validation by means of PAM. The configuration file /etc/pam.d/imap directs imapd to use general system authentication, so it will be controlled by that setting, either through authconfig or by direct customization of /etc/pam.d/imap yourself.

Note also that the "common name" field of the SSL server's certificate must match the name you configure clients with, or they will complain during certificate validation. Even if the two names are aliases for one another in DNS, they must match in this usage. [Recipe 4.7]

Our described configuration absolutely requires SSL for all IMAP connections. However, you may also want to permit unsecured sessions from localhost only, if:

• You also provide mail access on the same server via a Web-based package such as SquirrelMail or IMP. Such packages often require an unsecured back-end connection to the mail server. Perhaps you could hack them to use SSL, but there's little point if they are on the same machine.

• You sometimes access your mail by port-forwarding when logged into the mail server via SSH. [Recipe 6.14][Recipe 8.15]

You can permit unsecured IMAP connections by editing /etc/xinetd.d/imap (note "imap" and not "imaps") to read:

/etc/xinetd.d/imap: service imap {         ...         disabled = no         bind = localhost }

This accepts unsecured IMAP connections to port 143, but only from the same host.

8.9.4 See Also

imapd(8C), ipopd(8C). SquirrelMail is found at http://www.squirrelmail.org, and IMP at http://www.horde.org/imp.