Recently in Security Category

Do you know how modern email protection works?
Not really? You are not alone.

For a simple picture of email encryption most people think of a box in which they place their message that can be locked with a single key. Once the message is in the box and the box is locked, it can safely be handed over to someone (the mailserver) taking care of the transport to the intended recipient. This simple picture is not too bad because, in a way, that's what happens. But on the other hand this picture is fundamentally misleading to understand how email encryption really works. In other words, the reality is different.

If you follow this simple model alone, and many of us have no alternative, chances are, that you will make dangerous mistakes when you use email encryption or that you simply don't know how to use it. And that is not your fault.

Let me help you understand the basic idea behind modern email encryption to get a realistic picture of how it really works. A picture, that can lead you to do the right thing and to know why.

Why is the simple picture fundamentally misleading?

Because modern email encryption has two very different boxes used to lock a message. You probably haven't heard of the other type of box yet. But the second one plays the most important role in the whole process.

The Ordinary, Single-Key Box

Of course, there is a place for the ordinary box in email encryption that can be locked with a single key. In the real world such a box would come with a pre-fabricated key attached when you buy one in the shops. But the single-key box for email encryption works a little bit differently. You can buy a single-key box without a key and pick any key afterwards in a way you like, because a key is only a very, very large number. Once you lock the box with the key you have deliberately chosen (and nobody knows which one you took) the internal mechanism of the box changes in a way that this box (once locked) can only be opened with the same key or a copy of the same key. The experts today call this box the AES-box and the number you've selected the AES-key.

Well, the message locked in the box is ready for travel and the recipient receiving your locked box will only be able to open it, if he has a copy of the key you used to lock it.

I'm sure you see the problem that arises here. How would your partner on the other side know the key? Without the key it will be impossible to open the box.

That's a really hard problem, because you cannot attach the key to the box or send it with another courier. The key has to reach your partner in a safe way, or all security is lost.

The Invention of a Double-Key-Box

Some three and a half decades ago three clever guys invented an entirely different kind of box that revolutionized the digital world. The new box opened up new possibilities that were unthinkable before. I admit, there is no real-world example of such a box and that may be the reason why most people don't understand what they do when they use this kind of box in practice. And we all do use it when we surf the internet. Believe me, everything we do today to secure our online life is based on this new double-key-box. Paying credit to the inventors, experts call the new box the RSA-box.

How Does the Double-Key Box Work?

You can put a message into the box and lock the box with one key that you own. But once you've locked the box with this key you cannot open it with this key again, it remains locked. The only chance to get the box open again is to use a second key, which is a totally different one but which is related to the key used to lock the box. Both keys form a tightly bound pair where one key can undo the locking done by the other.

For email encryption those double-key-boxes are used to make sure that only one person is able to open the box, the recipient of your encrypted message.

But there was a problem, do you remember? You cannot send the key across the world together with the locked box.

Well, actually you can, and the message in the box will remain secure, too.

Sounds like a miracle? No, not at all, we now have double-key-boxes.

Imagine, you can make copies of your keys very easily. After all, keys are only large numbers. For email encryption to work properly, all you have to do is, make a key pair and circulate copies of one of your keys to everyone who may wish to send you an encrypted email. There is no risk in sending one key (the public key) out into the world so that everyone can get a copy. As long as the other key (the secret or private key) remains secret, all is fine. The secret key, on the other hand, has to be guarded as carefully as the crown jewels. If it falls into the wrong hands, all is lost (again).

What is really going on?

Before we can start to encrypt a message we have to get the recipient's public key. If we don't have it, we cannot do anything. I suppose you know why? To prepare our message for safe travel, we want to use a double-key-box and lock it with the recipient's public key. In doing so we make sure that the only person that would be able to open the box will be our partner, because only he has the corresponding secret key.

And what would he find inside the box after he has opened it? I bet you will be convinced that he will find our message inside. But no, actually he will find a key for a single-key-box in which we have placed our real message for travel together with the double-key-box. With this clever trick we have solved the problem of safe key transmission.

But only if we have used the correct public key to lock the double-key-box. If we happen to select the wrong public key, we are going to make a dangerous mistake. Not only will we give someone else the ability to open the box unintentionally, but we also prevent the intended recipient from reading our message. We are doing the complete opposite of what we intend to do, and we do not recognize that we've done something terribly wrong.

I hope, understanding the crucial part of the double-key-box will help you to avoid such terrible mistakes when you use email encryption in future. Now that you've come to terms with the basics of email encryption you will be immune to making silly mistakes, so go ahead and use email encryption.

Certainly not, if you store credit card information or passwords in clear text on the servers. Recent data theft disasters have shown, that it is not enough to operate a "secure server" and leave all customer's information unencrypted on this server. Because if you think your secure server is invincible, all your customer's data is at risk, the moment it turns out that the secure server is not as secure as you thought.

What's even worse, your customers have entrusted you with their data believing that operating a secure data center will be sufficient to protect their personal data from falling into the wrong hands. It's time to destroy this false belief.

Almost everything you'll learn to know about why you can trust an online shop or an online service provider boils down to the fact, that they make every possible attempt to secure their servers in the data center with all available bells and whistles of modern technology. But there is very little information - if any - about how they treat your data when it is stored on their secure servers online.

Of course I honestly value every effort to make online servers as secure as possible, but on the other hand I am convinced, that securing your online servers alone is not good enough. Let me explain.

A secure server is not invincible

Today most online services use a scripting language and a database server (think PHP plus MySQL for instance) and sensible information goes into a database. Usually the access to this database is given to every program that knows about the database password and normally runs on the same computer.

   It's a complete miracle to me, why after a default installation of some online shop applications the database password is stored in a file that could be read by any user on the system. It seems to be a commonplace belief that the server running the online shop is invincible, and therefore it poses no problem to store a database password in clear text without any additional protection. As we should know by now, secure servers are not always invincible and storing customer data unencrypted is a very bad idea. Not every online service is that careless about database passwords and it's easy to restrict access further, but today it seems to be the norm to dump the responsibility for the protection of customer data onto the administration personell in the online data center.

I wish to make the point, that we have to create online services in a way that if something goes wrong - despite the care to prevent this - customer data inside the online service is still protected against exploitation by intruders. And I'm convinced that such a protection is not only possible but absolutely essential if customers want to use online services securely.

Security and Convenience - Choose one.

As a consequence I'm sure that we have to correct another common misconception. You cannot have both, security and convenience in the online world. Forget it, you have to dump your notion of an easy, hassle-free, automatic and secure online service. Choose one or the other, you cannot have both.

That does not mean that secure online services have to be a pain in the neck but it certainly means that some procedures that have been introduced to make a customer's online experience "smooth", "seamless" and "easy" have to go if an online service that stores credit card information will ever be secure. Without knowing why, online customers will always think that some (unknown) data center professional is the right one to fight security problems, because after all they are in charge to make sure everything runs well. So it's vital that the ordinary online customer knows why some features of online services cannot remain the way they are today.

In their efforts towards making the online customer's life as uncomplicated as possible some vendors have started to encrypt their customer's sensible information. That's fine. But if you store the encryption key in a file next to the encrypted database, it's a little like locking your door and hiding the key under the door mat. This clever idea was born out of necessity, of course. As online customers demanded automatic payment from their online services there had to be a way that a program on a secure server could access the encrypted data (CC info for instance) without the intervention of a human being. The idea of storing the encryption key in some way on the server had been invented originally to ease the pain of the online customer.

If a customer wants to sign up to a service in the middle of the night (very convenient) the customer's data can either be stored in clear text (a bad idea) or, if it has to be encrypted, the key must be available to the web server program on the secure server (another bad idea). Surely, if you go fighting a bad idea with another bad idea, you'll never end up with a secure online solution.

Before you come to the conclusion that there cannot be a secure online service, let me tell you what I've learned during the last couple of months, while I tried to learn something from the data theft disasters and created a secure online service for small businesses, the secure online bills.

Secure Online Bills

An online service has to protect a customer's data even if there is an intrusion into the secure server, this is the fundamental principle that determined the design of my online service. It's really not easy to follow this principle at all times, because while I coded the system, I tried not to burden the user with avoidable inconveniences. But writing every single line of code myself made it clear to me that there have to be some decisions that will make the user's life a little bit more complicated. And it is inevitable, if the system should be secure.

I know, the last thing a customers wants is complications, "easy" is the marketing word not "complicated". But it became clear to me that there had to be more human intervention in the process if it should ever become more secure. So it is not complication that is inevitable. It's the introduction of the human factor into the process that makes it more reliable and secure.

What we need is more human intervention and less automation. I'm sure that if you begin to see, why it is necessary to rely on the informed decision of a human being instead of an automated web server process, the loss of convenience will become totally irrelevant. Making online services more human is the way to go, that's what I've learned from coding a secure online solution.

For instance, if you sign up for an online service and expect your login details to arrive via email within the next few minutes, your data cannot be secure, because the encryption key must be somewhere under the door mat. This is fine for demonstration purposes, and I use it myself for the secure booking service demo, but it's not good enough for the real thing, where customers rightly expect their information to be protected.

An online service cannot be secure when signing up is a matter of seconds. In fact, the setup of a secure online service requires manual work (of a human) on a server and of course some communication between the interested customer and the responsible person at the online service provider. The reason is simple, if the encryption key cannot be hidden under the door mat, it must be entered into the system from the outside in the moment when the encrypted information is needed. Using the system in a secure way requires preparation that cannot entirely be automated or, let me say, should not be automated at all, if you don't wish to encounter unpleasant surprises along the way.

What about lost passwords ?

Storing passwords in a database with the key under the door mat, no! Once the system is secure the database can only be re-encrypted with a key coming from outside the system. If you think the secure server should be able to reset your account easily, you're wrong. This would only be possible with a second emergency key stored on the server under a second door mat. No, the solution is to contact the service provider and make him use his emergency key which is safely stored outside the system to re-encrypt the database. That means, you'll have to wait until a human being does something useful for you. Is that too much of an inconvenience? I don't think so. Don't expect a server to do it instead. Get rid of this belief.

And if that takes time and costs money, be happy that your problem is being taken care of securely. And stop searching for a dirt-cheap, automatic way to have your negligence corrected without having to talk to a real human being.

It's amazing what you can do with SSL certificates. In an earlier posting I showed you how to secure your email access by using SSL certificates. To achieve this, we had fortified our mail server to always establish pure SSL secured connections for the retrieval of an users' email. We did that to stop network snooping folks to read email passwords in transit and to make sure that someone who got to know a user's password would even need another secret information (the user's SSL secret key) to get at the mailbox content.

Now we will use the certificates we needed to fortify our IMAP server to make the other half of the mail system, the SMTP server, secure too. The SMTP servers today are used to accept email messages that are bound for a certain destination for which the server is authorative. But to deny spammers the chance to indulge in their nefarious activities SMTP servers usually refuse to relay email messages to other servers under normal circumstances. There's nothing wrong with it as long as the machine that is used to send the email has a public IP address that was never used to send spam before.

But once you've tried to send email via a dial-up connection or a public wireless access point, chances are that your dial-up IP address is marked as a dubious source and you cannot send your email because you are blocked by some intelligent software that pretend to know your're a spammer. There is no point in arguing, your only chance is to send your email into the internet via a "clean" relay host, with a static IP address, that is able to make a difference between you and all the spammers that pretend to be you.

In essence, we have to find a way to authenticate ourselves to the clean SMTP server in a secure way. Obviously, all the system users that are listed in the mail server's user database should be allowed to use the server as a mail relay host. But then, they have to submit their passwords to the mail server to authenticate and, as you probably would have known by now, this should only be permitted through a secure link using SSL or TLS.

Switching On Authentication

Most people sending email don't think about having to prove their identities to a mail server, they expect to be able to send email the same way as they are used to stuff anything into a real letter box. From the perspective of the mail server, a correct username password pair is the only thing that differentiates a valid user from the spammers. That's why it is important to educate people, that giving a password is not too much of an annoyance for the benefit of sending email while on the move. Anyway, once we have set up the system to use SSL certificates with an outgoing mail server, users will not see much of a difference except that they have to provide their password when sending the email out.

Adding A Secure Tunnel To SMTP

As the mail server is our main secure entry point for email into the internet our main objective is not to hide our message but to convince the mail server that we are the good guys that are allowed to inject email into the system.

SASL, the Simple Authentication and Security Layer, is being used to enable our mail server software to perform the necessary authentication checks. But before we can enable the use of SASL inside postfix, we have to start a deamon, the saslauthd

The following code is used to enable sasl in postfix and has to be added to the main postfix configuration file:

The last few lines of code will tell postfix to use TLS (the replacement for the older SSL mechanism) and the location where to find the mail server certificate and key as well as the CA file to verify the trust chain.

With these modifications of the server side, we have essentially locked out everyone from using our mail server who is unable to provide the correct username and password over the TLS connection to our mail server.

Don't Forget Your Client!

The first thing we'll notice when we send our next email is that it won't go out as our email software used to ignore TLS so far for outgoing mail. To be able to send email out again you have to change your settings in the "SMTP" section of you email client software. After selecting TLS encryption and providing the username for the mail server you should be back on track again. In my case I had to upgrade my email software to ALPINE 2.0 to get busy, because my old software (pine) didn't know a thing about TLS. But that could only happen to me as I tend to stick to the old reliable programs when the rest of the world has already moved on to the cutting edge solutions.

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.