Recently in Cryptography 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?

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.