http://seifried.org/security/best-practices/ksbpa-001-ssl_imap_pop_linux.html
By Kurt Seifried, [email protected], Copyright Kurt Seifried 2001
Title:
SSL wrapping IMAP and POP on Linux systems
Issue date:
Sep 21, 2001
History of advisory:
Sep 21, 2001 First version of this advisory
Author:
Kurt Seifried [email protected]
Credits:
N/A
Overview:
Many Linux vendors ship software that allows users to SSL wrap IMAP and POP, but very few (none so far) make it easy for administrators to do so.
Vendor Contact:
N/A
Impact:
Most people are not using SSL wrapped IMAP and POP since it is relatively painful to setup.
Details:
Many sites and vendors now exclusively use SSH protocol for logins which protects usernames and passwords from exposure. Unfortunately many of these sites still use insecure protocols such as POP and IMAP which expose usernames and passwords. While almost all vendors ship the tools needed to SSL wrap IMAP and POP there is little or no actual documentation given on how to do so. Even vendors like Red Hat that ship preconfigured xinetd configuration files for SSL wrapping IMAP and POP leave administrators to properly create the certificates. The X.509 certificates used by SSL wrapped IMAP and POP must not be passphrase protected (i.e. PEM encoded) because each time you connect to an SSL wrapped IMAP or POP the server must access the certificate, which it cannot do if it is protected. Of course creating a certificate without password protection requires a customized configuration file for OpenSSL, which no vendors ship.
Solutions and workarounds:
The first step is to configure xinetd, typically the files reside in /etc/xinetd.d/, and you will need an "simap" or "imaps" file (check your /etc/services file with respect to port 993 and port 995) with the following:
service imaps
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/stunnel
server_args = -l /usr/sbin/imapd -- imapd
log_on_success += DURATION USERID
log_on_failure += USERID
}
And then restart xinetd. Of course connections will not yet work, you need a certificate. The location of the certificate can vary, for example on Red Hat it is typically:
/usr/share/ssl/certs/stunnel.pem
By pointing your IMAP or POP client at the server and trying to connect error messages will be generated, you can check /var/log/messages, and should see something like:
Sep 21 22:11:15 vomit stunnel[14083]: SSL_read (socket): Connection reset by peer (104) Sep 21 22:11:15 vomit stunnel[14083]: Connection reset: 3418 bytes sent to SSL, 338 bytes sent to socket Sep 21 22:11:15 vomit stunnel[14139]: /usr/share/ssl/certs/stunnel.pem: No such file or directory (2) Sep 21 22:11:15 vomit stunnel[14140]: /usr/share/ssl/certs/stunnel.pem: No such file or directory (2) Sep 21 22:11:15 vomit stunnel[14141]: /usr/share/ssl/certs/stunnel.pem: No such file or directory (2)
Of course using a stock openssl.cnf or stunnel.cnf to create the certificate will not work. You must modify the configuration file, typically in a location like:
/usr/share/ssl/openssl.cnf /etc/stunnel.cnf
Look for the section called "req_attributes", by default it should look something like:
[ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20
You will need to set the "challengePassword_min" to 0 so that you can create a certificate without protection that can be opened as needed. Once you have created the certificate you need to make sure that it is only readable by root, and definitely not writeable by anyone other then root. Depending on how stunnel was compiled it may or may not warn you about improper permissions:
Sep 21 22:27:35 vomit stunnel[14236]: Wrong permissions on /usr/share/ssl/certs/stunnel.pem
Assuming everything is setup correctly you should see entries like this in /var/log/messages:
Sep 21 22:12:17 vomit stunnel[14151]: stunnel 3.8 on i386-pc-linux-gnu PTHREAD+LIBWRAP Sep 21 22:12:17 vomit stunnel[14151]: imapd connected from 161.184.218.225:61879
And something like this in /var/log/secure:
Sep 21 22:12:17 vomit xinetd[2596]: START: imaps pid=14174 from=161.184.218.225 Sep 21 22:12:17 vomit xinetd[2596]: EXIT: imaps pid=14174 duration=5(sec)
Some things to remember:
If you want to keep the certificate file (*.pem) in a different location use the stunnel "-p" option to specify a different location, such as:
service imaps
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/stunnel -p /etc/imaps.pem
server_args = -l /usr/sbin/imapd -- imapd
log_on_success += DURATION USERID
log_on_failure += USERID
}
Older clients such as Outlook Express version 5.0 will accept any certificate for SSL wrapped IMAP or POP as long as the server name and date are correct, it can be signed by anyone, making a man in the middle attack very easy. You are strongly upgraded to upgrade to Outlook Express 6.0 which solves this problem partially. Netscape Messenger supports SSL wrapped IMAP but not SSL wrapped POP, there is no solution I know of for this.
If you can get an officially signed certificate (i.e. by Verisign) then clients will connect without any error or warning. Alternatively you can install the certificate on the client machine, with Netscape Messenger the dialog will prompt you for it, however in Outlook Express it will not. To install the certificate for Outlook Express simply point Internet Explorer to the URL:
https://your.mail.server:993/
or port 995 for SSL wrapped POP, and install the certificate through the standard certificate dialog.
Recommendations to vendors:
Ship preconfigured xinetd configuration files (Red Hat and several vendors already do this).
Document in these configuration files where the SSL certificate should be stored.
Provide a customized stunnel.cnf file which is setup with "challengePassword_min" set to 0 and document why the certificate cannot be protected.
Also document where this configuration file is and the command line needed to use it.
References:
None
Permission is granted for copying and circulating this Bulletin to the Internet community for the purpose of alerting them to problems, if and only if, the bulletin is not edited or changed in any way, is attributed to Kurt Seifried, and provided such reproduction and/or distribution is performed for non-commercial purposes.
Any other use of this information is prohibited. Kurt Seifried is not liable for any misuse of this information by any third party.
Last updated 4/10/2001
Copyright Kurt Seifried 2001