This page is part of the EmailServer article.
Foreword
This article describes the necessary steps to set up stunnel
to provide alternate secured ports for postfix and dovecot (SMTP and IMAP/POP).
This technique is useful but it is not necessary since you can achieve the same result just by modifying your firewall settings to redirect traffic from any port to the secured SMTPS, IMAPS/POPS ports already provided out of the box by postfix and dovecot.
You can directly proceed to the AlternateAccess article if you don't need to use stunnel
.
Secure, encrypted email channels
With the proliferation of wireless hotpots, people have been able to enjoy a new freedom in accessing the web and their emails: airport lounges, coffee shops, public spaces.
While all this freedom is wonderful, public access points (and most private ones) usually don't use any form of encryption to protect your transfers.
This is especially an issue on publicly accessible networks where absolutely anyone can eavesdrop on your communication without you being the wiser.
In some countries (including the US it seems), internet communications are routinely filtered, taped or analysed for whatever purpose is deemed just, too often without any accountability.
One of the reasons that email can be the weak link in your organisation security is that most of the time authentication connections by your email client are still sent in clear text, meaning that every time you get email, you advertise your username and password.
A lot of organisations only use a single username/password for each of their users and their access needs, meaning that the same pair is not only used for authorizing access to email accounts, but also to login into your PC, domain or Intranet...
Stunnel to the rescue!
There are many ways to secure your email connections through SSL: most servers have their own configuration details allowing them to work through an encrypted channel.
Here though, will will use Stunnel
to provide secured channels to postfix@2 and
dovecot@@ rather than configuring each of them individually.
Stunnel
is also easy to use and can allow you to create ad-hoc secure tunnels for any arbitrary network service as well.
Installing Stunnel
If Stunnel
isn't on your machine yet (whereis stunnel
), just grab it from your rpm
repository (yum install stunnel
) or get the source code from stunnel.org.
To install from yum
as usual:
To install the source code:
# cd /usr/local/src
# wget http://www.stunnel.org/download/stunnel/src/stunnel-X.XX.tar.gz
# tar xzvf stunnel-X.XX.tar.gz
# cd stunnel-X.XX
# ./configure
# make
# make install
Note that if you are installing on a RedHat machine, you may need to modify the files tools/Makefile.am
and tools/Makefile.in
to replace any occurrence of nogroup
with nobody
instead.
Note as well that the default installation directory is /usr/local/bin
. If you don't want this, use the --prefix
option of configure
(call it with --help to get more details about the available options).
Creating the private key and certificate
|
Creating a Self-Signed Certificate is only half of the story: since they are not issued by a recognised authority your mail clients will popup an information message to the user. The only way to solve this is to register your server with a recognized authority such as Verisign. This isn't necessary, but larger organisations may want to look into the details of providing this extra-security to their users as it ensures that your server is really who it claims to be.
|
To be able to encrypt the communication, Stunnel
needs to have access to a secure and unique private key and a certificate that it can issue to the clients connecting to it.
the certificate will contain information about your organisation and a public key that will be used by to encrypt data that can only be decrypted by the server running stunnel.
This step is important: don't use any default key that comes with your system: the communication channels would still be encrypted, but since these keys are publicly available, your communications could be decrypted without too much hassle.
To create the necessary keys just do the following:
# cd /etc/stunnel
# openssl req -newkey rsa:1024 -keyout privkey.pem -nodes \
-x509 -days 365 -out cert.pem
You will be asked a number of questions regarding your organisation. These will be included in the certificate issued by Stunnel
when contacted by clients.
Also make sure you use the FQDN (Fully Qualitified Domain Name) of your email server when asked about your server name (for instance, mail.example.com).
Note that the certificate will only be available for the number of days specified when creating it. You can make your certificate valid for as little or as long as you wish.
Now, Stunnel
requires that both certificate be in a single file with extra blank lines after each certificate.
Like most encryption-related configurations, it also requires that the certificate have limited access.
After creating the proper key, we don;t need the original ones any longer.
# cat privkey.pem > stunnel.pem
# echo "" >> stunnel.pem
# cat cert.pem >> stunnel.pem
# echo "" >> stunnel.pem
# chmod 600 *
# rm privkey.pem cert.pem
That's it, Stunnel
is ready to be configured:
Create the /etc/stunnel/stunnel.conf
with the following entries:
cert = /etc/stunnel/stunnel.pem
[imaps]
accept = 993
connect = 143
[pops]
accept = 995
connect = 110
[smtps]
accept = 465
connect = 25
What this does is simply tell stunnel
to listen to ports 993, 995 and 465 and spit out the decrypted stream of data to ports 143, 110 and 25.
The cert
line should not be necessary unless you compiled stunnel
from source and it is expecting a different path (check what it could be by running stunnel version
).
Now we can try to launch stunnel
manually to check that it works:
That's all that should be needed. If you are getting error messages, then try to add the path to your stunnel.conf
file.
If there are any other errors, we won't see them and stunnel
won't tell us whether eveything is fine or not.
To make sure everything is OK, have a look at the /var/log/secure
log file, it should end with the following lines:
... stunnel 4.08 on i386-redhat-linux-gnu PTHREAD+POLL+IPv4+LIBWRAP with OpenSSL 0.9.7f
... 500 clients allowed
If you get an error saying that the binding address is already in use check that your protocols
entry in the /etc/dovecot.conf
file doesn't contain pop3s
or imaps
.
To Allow Stunnel
to become a normal service like any other, we're going to install an init script for it.
A script is provided in the source code tree under tools/stunnel.init
but I recommend you get my copy instead as I have modified it to be manageable with the chkconfig
and service
utilities.
Install the service and schedule it to run:
# cp stunnel.init /etc/init.d/stunnel
# chmod 755 /etc/init.d/stunnel
# chown root.root /etc/init.d/stunnel
# chkconfig --add stunnel
That's should be all. You can check that stunnel
will start and stop by using service stunnel start
or service stunnel stop
.
Resources
< Firewall | EmailServer | AlternateAccess >