Fetch Your Email Through A
Secure Tunnel

In early October 2009 when news came up that quite a lot of Hotmail and Gmail accounts had been compromised by phishers who tricked users into using a faked login page the general advice for scared users was: "change your email password immediately". Although nobody really knew how the email passwords published on the internet were gathered, it became common knowledge that only those users who had used the phishing sites to log into their email accounts were vulnerable. Everybody else whose account was not blocked by the email providers started to feel safe again.

The fundamental problem with email is that access to the mail account is only protected by a password, and that every time a user fetches his email from the internet service provider (ISP), his password is transmitted to the mail server in plain text. To improve the situation email service providers are beginning to use opportunistic TLS, a method to encrypt traffic between mail servers. In this cases encryption is used if the mail server provides it, and in a perfect world mail would always travel encrypted to the user's mail server. But opportunistic TLS does not solve the user's problem as almost all email software he actually uses do rely on a password only to access an email account.

The Perfect Mail Server

In fact, what we have to do is to make sure that email is properly encrypted while the user fetches it from his email account, and that the mail server establishes a connection only if the person trying to get the mail is able to present more information than a password. This configuration would not only protect the email content and the password during transmission, it would as well ensure that someone only knowing the password would never be able to establish a connection to the mail server.

Fortunately this can be achieved without an additional burden on the user, because we only need a careful setup on the server side and provide the user with the additional information (a secret key) which has to be stored safely on the computer that initiates the mail transfer for her.

Setting Up A Secured Mail Domain

Let's start with the mail server configuration, which in my case is dovecot 1.0.7 on a CentOS server. I will show you how to configure dovecot to provide the mailbox of system users in a secure way. I assume that the firewall on the mail server is open for incoming mail on port 25 and that the mail server uses port 993 for outgoing secure IMAP traffic.

This is the essential part of the "dovecot.conf" file I use for secure IMAP access:
(I discuss the relevant parts of the configuration only)

protocols = imaps pop3s
listen = [::]

ssl_disable = no
verbose_ssl = yes

ssl_cert_file = /kx/dovecot/mail.senderek.ie.cert
ssl_key_file = /kx/dovecot/mail.senderek.ie.key
ssl_ca_file = /kx/dovecot/CAcrl-bundle
ssl_verify_client_cert = yes

mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n

auth default {
  mechanisms = plain
  passdb passwd-file {
      args = /kx/dovecot/%d/imap.shadow
  }
  userdb passwd-file {
      args = /kx/dovecot/%d/imap.passwd
  }
  ssl_require_client_cert = yes
}


First of all, by restricting the protocols to imaps and pop3s dovecot releases port 143 and 110 which could safely be blocked now. There are three certificate files which have to be in pem format. While the first file contains the public certificate for the mail server, the second must hold the unencrypted secret key. The file permissions on the later have to be restricted to read access for the root user as the key is read by the dovecot process before dropping permissions to the dovecot user.

The third file does not only contain the RootCA's certificate but also a valid Certificate Revocation List in pem format appended to the RootCA certificate with a newline in between. Without the CRL in this file the user's certificate cannot be validated and the connection will not be established. It is extremely important to keep an eye on this CRL, as the time frame for replacing a CRL is usually only a few days long. If you miss to keep the CRL part up-to-date you'll risk that the perfect mail server setup expires in a few days, leaving your users with no access to their email.

You can create long-living CRLs with the openssl crl command as you like, but bear in mind that the expiration date of your CRL does determine the ability of your users to get at their mail in the same way as does the expiration date of the user's certificate.

You may have noticed that in the authentication section everything is disabled except the use of two files which serve as a static user and password database. Only system users listed here are able to access their mailboxes. The two files "imap.passwd" and "imap.shadow" are exact copies of their system analogies, limited to the lines of valid email users. Just make sure that both are stored in a directory with the name of the email domain you use, which is shown as %d in the configuration file above.

Finally, the last line "ssl_require_client_cert = yes" determines that the mail server shuts down any connection if the user's email client is unable to present a client certificate, that the mail server can validate based on the content of the CA certificate file in the configuration.

By now we have made access to our mailboxes as difficult as possible, it's time to make it accessible for the user in a way that does not hurt. Please read on.

Supplementing The E-Mail Password With Certificates

What the user needs is a certificate, a public key, which is signed by the RootCA used by the mail server and a corresponding secret key. And, of course, a software that uses this information to download the email from the user's mailbox to the local machine over an encrypted tunnel. With another careful setup on the client's computer this is automatically done by the fetchmail process that can be run via cron in certain intervals. So the users receive their mail without bothering about the encryption process at all. They can read their internet email just like they read their local email.

Fetchmail uses a config file ".fetchmailrc" which has to be protected carefully (read access for the root user only) as it contains all the user's email passwords. It looks like this:

poll mail.senderek.ie protocol POP3

user joe@senderek.ie password PASXXXXXX is joe here
   ssl sslcertck sslcert /certs/joe@senderek.ie.cert
   sslkey /certs/joe@senderek.ie.key

user patrick@senderek.ie password PASXXXXXX2 is paddy here
   ssl sslcertck sslcert /certs/patrick@senderek.ie.cert
   sslkey /certs/patrick@senderek.ie.key

For the client to establish the SSL connection it is not enough to present the public certificate to the mail server, it is also necessary to be able to use the secret key. And this is what the attacker who may have learned the email password will not posses and what will keep him out of our mailboxes.

If you have trouble creating those certificates, please drop me an email and I will see what I can do for you.