Recently in Security Category

You may have followed my advice I gave in an earlier posting to set up a secure email server that will allow clients to fetch their email from the server only if they present a valid SSL certificate in addition to the usual password for the mailbox user. The most appealing aspect of this approach is that once the system had been set up, the client user, who has already stored his certificate on his local laptop will just have to provide the password as usual. This solution comes with no additional burden, and at the same time ensures that the email travels encrypted from the email server to the laptop. A clear boost of security, fine.

The only problem is that the email client software must be capable of establishing a SSL connection using the users certificate. Unfortunately not every prominent email software is able to do that. In my case I fetch my email from the server with fetchmail as I'm interested to archive all incoming email.
But email software usually tends to fetch the email on its own account. So the lack of being able to establish a SSL connection could clearly ruin the new approach.

What's Written On The Tin?

As a consequence I was very surprised to learn that Evolution, generally being celebrated as the Outlook killer software, actually is one of those culprits. Googling towards a solution I came across some well-intended advice "just" to upload the my certificate using the pertinent buttons in Evolution. This is good advice although it requires a little bit of openssl hacking to beat the two separate cert and key files in shape to form a p12 file, but it doesn't solve the problem at all. Evolution uses uploaded certificates to sign messages a user sends to other people, but it still refuses to use such a certificate to establish a SSL connection to the mail server. Strange, but true.

Let The Expert Do The Connecting

Fortunately there is a small but powerful piece of software that is rapidly becoming my favorite tool in such situations, called STUNNEL. Its primary goal is to read data from one port and to connect to an entirely different port on a different computer, initiating a clean SSL connection with the certs and key provided in a single configuration file. From the remote server's perspective it looks like some SSL capable software had connected to the server, while indeed any dumb non-SSL-aware code is using stunnel to do the hard work. This code could as well be Evolution, right? Let's have a look at the simple config file for stunnel:


Essentially, the "normal" IMAP port 143 on the laptop is wired as a secure IMAPS mail server to be used by Evolution. All certs and keys are stored in a secure place on the laptop.

Getting Evolution To Use The Tunnel

The remote mail server mail.kerrylinux.ie would usually be listed as the server in the settings for "Receiving Email". Now you just have to replace this entry with the local laptop's name and make sure that "no encryption" is selected. Remember it is STUNNEL's job to perform the SSL encryption not Evolution's. "Yes, but it should be evolution's", I can hear you say. You're right, but even if the evolution team decides to sex up their software in future, this solution will work for every other non-SSL capable email client as well, and that's the reason why I told you how to do it.

On the last day of the year my email stopped coming in. You may have read about my approach to fetch my email using a secure tunnel that uses SSL certificates in addition to a password to access my email. Well, on the last day of the year my ROOT CERTIFICATE, which I use for Kerry Linux, had expired after five years. Time flies by.

As I had other plans for the days ahead I thought just to renew the root certificate to buy time, but it seemed that my attempts to renew my root certificate did not result in a new usable certificate to replace the old one. My user certs, which are not up for expiration yet could not be reanimated with a quick fix like that.

After a while I thought, there is a reason for that and I began to think about root certificates more thoroughly. In the past five years we've definitively seen the crackdown of MD5 and SHA-1 is not invincible, too. Would it not be prudent to increase the key length and to use a more secure (i.e longer) hash and go through the trouble of creating a new root key and issue new user certs? I decided to go along that route and created a fresh new CA root key with 4096 bits for the Kerry Linux Certification Center. Although my openssl software does only permit using SHA-1, which is a pity, I felt content and everything was up and running for me in an hour or so.

Re-Animation of the old ROOT KEY

After a while I began to wonder if it was possible to reanimate the old key and out of curiosity tried to explore the way to do it in more detail. I googled and found this nice posting from Arsen Hayrapetyan which led me to success. My former attempts to recreate the old certificate always led me to the following error message when I tried to verify a user's certificate::

Unable to get the issuer certificate? I supplied it in the command, but it didn't work out as planned.

So I followed Arsen's hints and created a testbed for an experiment, where I set the serial number back to 00 and emptied the file "index.txt" so that my new certificate could inherit the properties of the old one including its serial number. Then I created a new certificate request based on the old root certificate "cacert.cert" and used this new request to sign it with the old key.

The result was a new root certificate "cacert_renewed.pem" that verified my old user certs perfectly.

It's good to have an alternative, isn't it?

Current Phishing Attacks

In early October 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 clear 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)

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 the 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 Mail Password With SSL 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:

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.

The Final Nail in WEP's Coffin

I have to admit it, this is old news, very old news. WEP is dead, and the final nail had been driven into WEP's coffin some three years ago. But many WiFi networks still use WEP today, although a much more secure alternative, WPA-2, has been available for a long time.

People tend to believe that any encryption is better than none and don't bother to use high-grade security methods instead of broken ones like WEP. Obviously the publication of research papers does have a limited effect on the ordinary user's willingness to change habits or consciousness of the problem. Unless the weak methods disappear from the router's firmware menu, we'll see people using it.

Switching Over to WPA

It's fairly easy to dump WEP and to use WPA-2 instead, because WPA-2 can use a pre-shared key, a secret that must be available both in the router or access point and in the client machine that is about to establish a secure wireless connection. There is clearly no need to add further complexity (like Radius servers and the like) just to replace WEP for a simple wireless link.

In a first step you have to change the security settings of the access point / router to WPA2-PSK and select a new long secret key for encryption. As WEP-2 uses the advanced encryption standard (AES) with a 256 bit key, the new secret key ought to have as much entropy as possible. You can use the following command to get a reasonably long random secret (of 160 bit entropy) for use by the router and the client.

After that your wireless client is cut off, as the router makes use of a different, and more secure, access method. It's prudent to use a new secret key as your encryption has been weak in the past and the old one might have been compromised long ago, you'll never know for sure.

In order to re-establish the wireless link the client machine will use a daemon software called wpa_supplicant that has to be started just before the wireless network adapter starts to reach out for the access point or router. Of course the wpa_supplicant will need at least two pieces of information, the name of the wireless network (its SSID) and the secret encryption key, we've already stored in the router. Please double-check that the daemon's config file has minimal permissions (root read access only) to protect the wireless secret key and add something like the following lines to your config file "/etc/wpa_supplicant/wpa_supplicant.conf":

The only thing you need to ensure is, that the daemon is started whenever you use your wireless adapter, and that the firewall recognizes your new link. Yes, it's that easy to dump WEP for good. Finally.