Secret Letters

From the point of view of a mail server, and therefore also its administrator, emails are simply ASCII text files that are transferred from server to server. They end up on the filesystem both in transit and at the destination as a text file that is freely readable for the administrator. Reading mail is no problem for administrators, even if the individual message is quickly lost due to the huge numbers. But if you know what you are looking for, you can read whatever you want. Cyber criminals often hack email inboxes and systematically analyze the messages they find.

Email has existed for a generation, and the problem of email security is nearly as ancient. This article offers some thoughts on the state of email encryption today, including what works and some complications you might want to know about.

SSL/TLS and Beyond

The first step in securing email is securing the communication channel. Most well-known and responsible providers now provide secure connections to and from their mail servers by means of SSL/TLS encryption, so that the data crosses the Internet in an encrypted format.

It would be great to say all email providers offer secure communication with SSL/TLS, but that is not the case. Gaps remain, often with very old, unmaintained mail servers in settings where a commercial firewall or spam filter does not easily support SSL/TLS. Old Exchange servers that are directly accessible on the Internet for mail reception often stand out due to their lack of encryption capabilities. The good news is that whenever Linux-based mail servers such as Postfix are used, SSL/TLS is usually offered as a matter of course.

The sender neither can see whether, or assume that, a message is encrypted using SSL/TLS. Mailbox.org was the first provider to introduce a procedure that shows the user whether and how the target system can be reached via SSL/TLS as soon as the email is written. Other providers have now copied and implemented this procedure.

Simply enabling SSL/TLS is not enough today. Because encryption is optional with the Simple Mail Transport Protocol (SMTP), a man in the middle could prevent the SSL connection and force an unencrypted plaintext connection. Alternatively, an attacker could swap the SSL certificates of the mail servers for their own certificates. But there is a remedy for this, too. The DNS-based Authentication of Named Entities (DANE) [1] standard, which has been available for several years, defines how mail servers can publish the fingerprints of the SSL certificates they use by means of matching TLSA type DNS records. This step effectively prevents manipulation or suppression of the certificates by third parties.

But DANE has only been used to a limited extent. Data-protection-savvy mail providers such as Mailbox.org, Mail.de, and Posteo were early DANE adopters, and several other providers have followed suit, but many email providers still find DANE very difficult to use today. The reason is that publishing the certificate fingerprints via DANE only works if they themselves secure the DNS zone against manipulation by means of DNSSEC. However, DNSSEC presents some infrastructures with greater challenges, so many IT managers are wary of taking the step.

Postmasters who have a DNSSEC-secured domain can publish the checksums of their certificates in just a few simple steps. Special websites [2] help to generate the required TLSA-type DNS record. But be careful: Every time you change the SSL certificate in the future, you also have to remember to update your own DANE record. Mail servers with a state-of-art configuration like Postfix will stop outgoing mail if the certificate and fingerprint published via DANE do not match or if a target does not offer SSL/TLS even though a DANE/TLSA record has been published. The main.cf file of the sending mail server needs a smtp_tls_security_level = dane line, even if the server does not offer DANE for incoming messages.

Securing the Contents

SSL is in place. Is everything fine? Not at all, because SSL only secures the TCP/IP connection between two specific mail servers. No one knows whether the message might be transmitted over unencrypted connections further down the line. In addition, the email itself ends up in plaintext on the servers, both in the recipient's inbox and in the sender's Sent folder.

In an electronic mailbox that has operated for years, perhaps even decades, many highly personal things could exist that you would probably prefer to keep out of the public eye. Every user needs to ask what impact it would have if their entire email inbox became public, because that can happen all too quickly. A poorly chosen IMAP password can be easily hacked; it may have even been revealed in an inattentive moment to a phishing site or intercepted by a local virus infection.

The only way to ensure that your email will remain private is to encrypt the messages using PGP or S/MIME. Both methods are based on the same principle: Each user has an asymmetric key pair. It consists of a public key, which is used for encryption and a digital signature, and a private key, which is used for decryption and verification of a digital signature. A password chosen by the user protects the private key against unauthorized access. This password must not be forgotten under any circumstances. If it is lost, the key file is unusable, and all data encrypted with it can no longer be accessed.

Pretty Good Privacy

Many Linux users today are accustomed to working with PGP. You store your own public key, together with those of other recipients in a local key database, also known as a keyring. Since several keys can be generated for a mail address over time, each key has its own ID. In addition, the authenticity of a key can be verified using a mathematically unique fingerprint. This fingerprint can be published on business cards or in your web imprint or verified by phone, which allows communication partners to ensure that they really have the right key.

Generating a public/private key pair is quite simple nowadays and usually occurs automatically the first time you use the PGP software tool. The public key can then be transmitted individually or automatically to communication partners. Mail programs such as Thunderbird offer to attach the public key to an outgoing email at the push of a button. You can also upload the public key to public PGP key servers, where interested parties will find it automatically.

Once a key has been put into circulation, it can no longer be deleted, but it can be declared invalid in the event of key theft or password loss. To declare a key invalid, you should generate a revoke certificate ahead of time (i.e., immediately after generating the key) and store it in a secure place in your own filesystem. If your own password is lost, you no longer have the option of creating a revoke certificate. In addition, keys should not be issued for an indefinite period of time but assigned an expiration date a few years in the future.

All of these options are usually found in the mail program's key manager. Press the right mouse button to call up the properties and potential actions for your own key (Figure 1).

Figure 1: Your mail program's key manager should offer several options for managing keys.

One problem remains: It is initially impossible to verify whether a key actually originates from the owner of the mail address. Attackers can easily generate their own PGP keys for any mail address and put them into circulation. The public PGP keys of other users are therefore initially considered untrustworthy in your own keyring. However, the sender and recipient can have the specific PGP fingerprint displayed there and verify it via another communication medium – by making a short phone call if necessary.

So much for the theory. In practice, many users today use the keys they receive without verification. In the settings of most popular mail programs, you can define the trust level from which a key can be used for sending. This is certainly not ideal and could convey a deceptive sense of security. On the other hand, using any kind of encryption is better than having none at all, so in the interest of the matter at hand, just take a pragmatic approach if in doubt. A received key is insecure if it has been manipulated by a third party at the time of receipt and the compromised key is trusted permanently. But if you assume that the key exchange (which may have occurred long ago) was secure at the time, then the key can successfully provide protection against future unwanted readers and the dreaded man in the middle.

Since manual checks are not a good way to handle large numbers of communication partners, PGP implements the concept of a web of trust. After careful personal verification of their identity, users sign the keys of other users (Figure 2), thereby increasing their trustworthiness. The signatures then become part of the user's public key (Figure 3). If, at some point, keys have a sufficiently good reputation due to the many signatures of known trustworthy communication partners, you can do away with your own manual verification. Even today, PGP keysigning parties are held at conferences. You have to bring your own PGP keys and, by default, your ID card or passport as proof of identity, because careful verification is mandatory.

Figure 2: Signing a third-party key increases its trustworthiness and requires appropriate care.

Figure 3: The properties of a key show its fingerprint and the signatures of other users.

But the concept of mutual PGP signing is complex, requires initiative, and requires a great deal of interaction – one of the main reasons why PGP has never gained widespread acceptance. Modern approaches therefore envisage publishing your own PGP key via special key servers run by your provider, from which communication partners can obtain it automatically. Although this approach does not rule out manipulation by the provider's administrators, it does ensure that keys can no longer be generated and circulated arbitrarily by third parties. Using methods such as WKS/WKD [3], domain owners can therefore specify whose PGP key servers need to be queried for the keys for their own domain. However, only a few providers systematically offer PGP key servers and have set up corresponding WKD records for their mail domains. If they do, nothing stands in the way of an automatic key exchange. PGP implementations such as GnuPG can then automatically detect the correct key servers and download key material.