Infoturve - Kursused - Arvutiteaduse instituut

Introduction: How email exchange works

Simple Mail Transfer Protocol (SMTP) is used to transmit emails both between the user and email server and between the mail servers. However, email client software is commonly configured to use SMTP only for sending emails. In order to receive emails client software uses either IMAP or POP3.

IMAP protocol is commonly used nowadays as it provides support for multiple simultaneous clients. Therefore, with IMAP it is possible to view emails in both the smartphone and in a laptop without the emails being deleted from the server. However, POP3 is an older protocol that first fetches the mail and then deletes it from the server which means that by default mail can be downloaded to a single device.

One might wonder if SMTP, IMAP and POP3 always encrypt the email traffic in order to protect confidential information from leaking. Actually, all of these protocols support the transmission of data over SSL / TLS but this is an optional feature. Special ports are reserved for these protocols to transmit data over SSL / TLS. Secure SMTP is called SMTPS and it uses port 465. Secure IMAP is called IMAPS and it uses port 993. Secure POP3 is called POP3S and it uses port 995. It is obvious that the extra S in the abbreviations stands for secure and it just means that the protocol is used inside of a SSL / TLS session. Most email servers support the secure versions of these protocols but the user may have to configure the email client software to use the correct port.

Source: Wikimedia

There is a feature that enables encryption even for the plain SMTP, IMAP, POP3 and this feature is called STARTTLS. STARTTLS adds SSL / TLS by default if the corresponding mail server supports this. Most well known email providers have enabled support for STARTTLS. However, if a mail server does not support STARTTLS, then the user will have to configure the email client software to use a port that provides an encrypted connection.

Security and privacy issues of email exchange

The protocols that are used to exchange emails are not designed to take security and privacy seriously. These protocols were designed to get the job done in an environment where security was not so relevant. However, these protocols are still alive and it is difficult to modify them or to replace them with more secure protocols.

By default email is not encrypted, some links between the mail servers might be encrypted but this does not mean that the content of the email can not be intercepted, read and modified. It might be possible to encrypt the links between the mail clients and mail servers but while the mail is routed through the Internet it might pass servers that do not support encryption. In addition, as the content of the mail is not end-to-end encrypted, the mail servers are able to read the contents of the emails.

Some SMTP servers support STARTTLS which enables to automatically switch from an unencrypted connection to an encrypted connection over SSL / TLS. However, STARTTLS is mostly supported by the major email providers and many servers still do not provide this option. When STARTTLS is not available and the mail client is not forced to use a secure mail exchange protocol then the email is exchanged in plaintext, i.e., in an unencrypted form.

A message transfer agent (MTA) is used to relay emails from one mail server to another. MTA uses SMTP and deals with receiving messages and relaying messages. It is important to note that MTA-s do not have to communicate with each other over TLS/SSL. If one of the MTA-s does not support TLS/SSL then the email is exchanged in plaintext. In case an email is sent to a mail server that does not support TLS/SSL then it is guaranteed that the email will be transmitted in plaintext at least in one transmission step. Therefore, STARTTLS and secure mail exchange protocols do not provide confidentiality during the transmission of the email as one of the mail servers might not support TLS/SSL. Even when all links during the transmission of the email are secured by encryption the contents of the email can leak as the mail servers are able to read the email in plaintext. Therefore, one needs to trust the MTA-s while sending emails but this is not a very wise thing to do when the contents of the emails are confidential.

Source: OASIS

In addition, it is important to notice that the metadata in the header of the email can not be encrypted as this information is required for relaying the emails. Therefore, it is possible to intercept the metadata that contains: sender email address, recipient email address, sender IP, recipient IP, date, time, title of the email. This data is public and the mail exchange protocols do not provide means to protect such information.

Risks that are related with email communication:

the contents of the emails can be intercepted and saved
the contents of the emails can be modified
the contents of the emails can become public information
it might be possible to use someone else's identify

A very good overview of the security issues of email is given by the article Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security (2015). It is written by researchers from University of Michigan, Google, University of Illinois.

Solution for the privacy and security issues

There is no ideal solution for the described security and privacy issues. The best available solutions use end-to-end encryption but they are not widely used. In end-to-end encryption the message is encrypted in the sender's computer and decrypted in the recipient's computer, which means that the intercepting party can not get access to the contents of the message. End-to-end encryption of emails is provided by PGP/GPG and S/MIME. As an alternative, it is possible to use other communication means that provide end-to-end encryption. One popular alternative used to be Off-the-Record Messaging (OTR) but nowadays Signal is considered to be one of the most secure communication applications.

Once you have finished reading the following theory part, you can attempt to solve the bonus task by using PGP/GPG to encrypt and sign emails.

S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a mail exchange standard that is based on public key infrastructure. In addition to providing confidentiality by using encryption, non-repudiation by using signing, it also provides authentication and message integrity. Similarly to HTTPS, each end user should have a key pair and a certificate that binds the identity (email address) with the corresponding public key. The certificate has to be signed by a trusted certificate authority (CA).

In order to encrypt emails with S/MIME one would need to have the public key of the email recipient. Usually the public key can be accessed if the recipient has previously sent a signed email which contains the certificate and therefore also the public key.

S/MIME is supported by several mail clients but it is rarely used as one would have to get a certificate that is signed by a CA. However, S/MIME is widely used in Estonia as each ID-card owner has a certificate signed by a CA. It is possible to send encrypted and signed emails using the Estonian ID-card. In order to do that one would have to search for the corresponding certificate and then use the email address that is in that certificate. The email addresses in the ID-card certificates are of the following format: Surname.Lastname[.X]@eesti.ee.

PGP and GPG

Pretty Good Privacy (PGP) is a computer program that was created in 1991. It allows to encrypt and sign documents and emails. Similarly to S/MIME PGP is based on public key cryptography. Each PGP user has a key pair but it differs from S/MIME by the way how keys are managed. PGP is not centralized, i.e., it does not use public key infrastructure. Therefore, one does not have to get a CA to sign a certificate which makes it easier to start using PGP.

Instead of using public key infrastructure where trust relationships are created between CA-s, PGP uses something that is called a web of trust. In the web of trust everyone can choose how much trust is given out and then the decision is bound by signing the corresponding certificate. If many people enforce the trust by signing other peoples certificates then a social network of trust is created where trust is a transitive relation as shown on the following figure.

PGP trust relations. An ordinary arrow denotes that a certificate has been signed and the dotted arrow denotes a trust relationship. For example, as Dave trusts Alice and Alice has signed the certificate of Bob, then by the transitive relation Dave also trusts Bob, i.e., Dave believes that the corresponding public key really belongs to Bob. (Source)

Key servers are used to manage the trust relationships. One can download a certificate from the key server and also upload new signed certificates to the key server. Therefore, everyone can create new trust relations and publish them in the key servers.

Source: XKCD

Actually, PGP is an old commercial software product and therefore it is not used anymore. A standard called OpenPGP was created based on PGP in order to make the functionalities provided by PGP widespread. OpenPGP is supported by different software products which makes them interoperable. The most common and widespread software that follows the OpenPGP standard is GNU Privacy Guard (GnuPG or GPG). GPG is an open-source program that is available for free.

GNU Privacy Guard (GPG)

GPG allows to exchange emails and attached files in a secure manner. GPG allows to encrypt and sign emails which means that a third party is not able to secretly modify or read the contents of the emails. In addition, when an email is signed the the receiver can be sure who sent the email (actually, the receiver only knows that the sender had access to the corresponding private key).

GPG is considered to be one of the safest methods for encrypting data. However, GPG is not very popular and only a small group of people communicate by using GPG. Therefore, one can usually start using GPG only if the receiving party is instructed on how to setup GPG. There might be a situation when someone, e.g. a client, wants to submit confidential information and GPG provides a solution for this problem. Estonian citizens can use the encryption and signing functionalities provided by the ID-card but if the client is a foreigner then ID-card may not be an option. In such cases one could create an OpenPGP key pair for himself / herself or for the company. However, just creating the key pair is not enough, the key pair would also have to be published so that the clients could find the key. One option is to publish the key in addition to the key servers also to the company website in case the website is configured to use HTTPS.