Email Security/Privacy Back to Home Page

How does one go about sending and receiving private messages without having to worry about someone invading your privacy? The simple answer is that it is not simple. Some people are under the illusion that TLS (Transport Layer Security) provides protection, but nothing could be further from the truth. As the name suggests, TLS only provides protection during a single transport leg. It does not protect the message at the source or the destination, nor any of the MTA's in between. In one respect TLS is overkill because it encrypts everything, when in reality the only component that really needs to be encrypted is the message itself.

So why do the big three use TLS for sending email? They are not saying, but it would be my guess that they are simply trying to limit abuse. It is quite easy to create a script to send email, so adding TLS limits the number of potential abusers. And because they offer world wide service, they have virtually no control over the networks connecting to their servers. Adding TLS helps protect against password snooping, as one of the biggest problems they have is account hacking. For them, TLS is a reasonable limitation for using their servers to send email, but it does little to protect messages originating from the thousands of other servers.

You could subscribe to a Secure Email Provider. But how do you know your email is really secure. These services all rely on the use of Public/Private key pairs. And guess who controls those keys? And guess who could be coerced by big brother into giving up those keys? History already tells us that it is not outside the realm of possibility. And what about the complexity of managing those keys? Most non-technical users don't have a clue about how to load a key or how to keep it safe.

The only way to truly protect a message is to encrypt it at source, and decrypt it at the final destination. Using Asymmetric Encryption, one end encrypts with the Public Key, and the other end decrypts with the Private Key (or visa versa). The Private key only has to be transferred one time. That is until the possibility arises of the Private Key being compromised. Then that key must be revoked and a new one issued. Because the Public Key is just that (public), the keys have to be relatively large and consequently resource hungry in comparison to Symmetric Keys. To give you an idea, an RSA 1024-bit Asymmetric Key is considered roughly equal to an 80-bit Symmetric Key. Symmetric Keys use the same key for encryption as for decryption, so each time they are used they must be unique. That means they must be transferred each and every time they are used. And that presents a significant challenge as well. Think about it. To get access to all Asymmetric traffic from a particular machine, a hacker only needs to hack one Asymmetric Key. To get access to all Symmetric traffic, a hacker has to hack every single one. If you were a hacker, where would you spend your resources?

Just like TLS, JACMail uses a combination of Symmetric and Asymmetric Keys. The current version of JACMail (2.5) uses ECC (Elliptical Curve Cryptography) to transfer the decryption key. The sender generates the message key and passes it to the sender's server. The receiver sends the Message Identifier and its own public ECC key to the senders server. The server uses it's own private ECC key and the public ECC key from the receiver to generate an Agreed Secret. This Agreed Secret is then used to encrypt the message key recovered from it's database, and is sent along with it's public ECC key to the receiver. The receiver uses it's own private ECC key and the public ECC key from the sender to generate the same Agreed Secret, and then uses the Agreed Secret to decrypt the message key. The decrypted message key is used to decrypt the actual message, and the message key is stored in the receiver's database. Subsequent decryption by the receiver uses the stored message key.

Encryption is of course only part of the solution. One must also protect the account, and this requires strong passwords that are periodically changed. Some sites have taken to using dual passwords, or a password and a computer generated pass code. The reason for this is that guessing a password is a relatively easy task. All you need to do is keep guessing until you find the one that fits. The fewer the characters used, the easier it is. Most servers will lock out an account for a period of time after several invalid attempts, but good scripts will space out the attempts to overcome this limitation. Our SMTP server gets hit daily with several hundred AUTH LOGIN attempts. These attempts often come from the same source but different IP addresses, identifying themselves with an EHLO of ylmf-pc. The strange part is that our server does not support AUTH LOGIN, and advertises such in it's response.

The next issue to consider is certification. Is the individual you are communicating with really the person you think you are dealing with? This one is far more difficult because of the way the Internet works. DNS caches can be poisoned to direct an individual to a site other than the one they desire. When it comes to email, why should we be concerned if our email uses a server other than the one we currently trust? Because the email is encrypted, our only concern should be that it makes it to the intended recipient. JACMail records when the recipient recovered the key and the IP address used to recover that key. This information can be used to verify that it was indeed the intended recipient. That is true if the intended recipient receives your message, and not one generated by a hacker. If the hacker sent a false encrypted message, then he/she must also make sure the recipient uses their server to recover the key. This can be accomplished by poisoning the DNS cache that the recipient uses to direct them to a server the hacker controls. The way around this is to not rely on the DNS system, but rather to program the server location into the HOSTS file on the client machine. Not only is the response much faster, but it allows for a much simpler and faster IP address change on servers using a dynamic IP address.

Another issue is HTML. I have always maintained that HTML does not belong in a messaging system. That is why JACMail does not directly support HTML or embedded objects. You have the option of sending HTML to your default web browser to read, but it comes with a degree of risk. HTML can contain blind scripts, which can be used to load malware on your computer. At the very least, an embedded image linked to a foreign server can be used to tell the sender when you read the email, what IP address was used, what operating system you are using, and what software was used. If you are using software that directly supports HTML and want to know how vulnerable you are, you can use the following site: https://emailprivacytester.com/

The question you need to ask is "Who can I trust?". When it comes to the Internet, the answer is no one. If you rely on someone else to provide that trust, there will always be doubt. If you can control the bulk of the functions yourself, then you limit your exposure. JACMail does just that. The downside is that both ends must use the same software, and that will remain the case until such time as standards can be developed that really address email security/privacy.

Back to Top

| Home Page