Encryption

Ever since email became the primary electronic communication medium for personal and business purposes, a legitimate concern over privacy and authentication has arisen. In general terms, the email format is transmitted in clear text, similar to a postcard which anyone could read. Moreover, as assimilating false identities is an easy process, it is important for the recipient to be able to tell if the sender is who they claim to be.

Solutions to these issues are typically accomplished with email encryption and digital certificates, where an email message is electronically signed and cryptographically encoded. This assures that the message recipient exclusively can open and view the contents of the email (privacy), verifying the identity of the sender (authentication). In other words, this process negates the idea of being sent an "e-postcard", and introduces a process much like registered or certified mail.

Modern cryptography has two methods to encrypt email: symmetric and asymmetric. Both have become standard methods and are utilized in several types of applications. Symmetric key cryptography refers to encryption methods in which both, the sender and receiver, share the same key.

On the other hand, asymmetric key cryptography (also known as public key cryptography) is a form of cryptography in which each user has a pair of cryptographic keys; a public key, which encrypts data, and a corresponding private or secret key for decryption. Whereas the public key is freely published, the private key will be securely kept by the user.

One drawback with symmetric encryption is that for a sender and recipient to communicate securely, they must agree upon a key and keep it secret between themselves. If they are in different physical locations, they must prevent the disclosure of the secret key during transmission. Therefore, the persistent problem with symmetric encryption is key distribution: how do I get the key to the recipient without someone intercepting it? Public key cryptography was invented to exactly address this problem. With public key cryptography, users can securely communicate over an insecure channel without having to agree upon a shared key beforehand.

The need for email encryption has produced a variety of public key cryptography standards, most notably S/MIMESecure/Multipurpose Internet Mail Extensions and OpenPGPPretty Good Privacy, both of which are supported by Sophos UTM. S/MIME (Secure Multipurpose Internet Mail Extensions) is a standard for asymmetric encryption and the signing of emails encapsulated in MIME. It is typically used within a public key infrastructure (PKI) and is based on a hierarchical structure of digital certificates, requiring a trusted instance as Certificate Authority (CA). The CA issues a digital certificate by binding an identity to a pair of electronic keys; this can be seen as a digital counterpart to a traditional identity document such as a passport. Technically speaking, the CA issues a certificate binding a public key to a particular Distinguished Name in the X.500 standard, or to an Alternative Name such as an email address.

A digital certificate makes it possible to verify someone's claim that they have the right to use a given key. The idea is that if someone trusts a CA and can verify that a public key is signed by this CA, then one can also be assured that the public key in question really does belong to the purported owner.

OpenPGP (Pretty Good Privacy), on the other hand, uses asymmetric encryption typically employed in a web of trust (WOT). This means that public keys are digitally signed by other users who, by that act, endorse the association of that public key with the person.

Note – Although both standards offer similar services, S/MIME and OpenPGP have very different formats. This means that users of one protocol cannot communicate with the users of the other. Furthermore, authentication certificates also cannot be shared.

The entire email encryption is transparent to users, that is, no additional encryption software is required on the client side. Generally speaking, encryption requires having the destination party's certificate or public key on store. For incoming and outgoing messages, email encryption functions as follows:

• By default, outgoing messages from internal users will be scanned, automatically signed, and encrypted using the recipient's certificate (S/MIME) or public key (OpenPGP), provided the S/MIME certificate or OpenPGP public key of the recipient is existent on Sophos UTM.
• Encrypted incoming messages from external users whose S/MIME certificate or OpenPGP public key are known to Sophos UTM will automatically be decrypted and scanned for malicious content. To decrypt the message, the S/MIME key or OpenPGP private key of the internal user must be existent on Sophos UTM.
• Encrypted incoming messages from external users or for internal users unknown to Sophos UTM will be delivered, although they cannot be decrypted and therefore not scanned for viruses or spam. It is then the responsibility of the recipient (internal user) to ensure that the email does not contain any malware, for example, by using a personal firewall.
• Outgoing messages already encrypted on the client side will directly be sent to the recipient if the recipient's S/MIME certificate or OpenPGP public key are unknown. However, if the recipient's S/MIME certificate or OpenPGP public key are available, the message will be encrypted a second time. Note that pre-encrypted messages cannot be scanned for malicious content.
• Decryption is only possible for incoming emails, where "incoming" means that the domain name of the sender's email address must not be part of any SMTP profile. For example, to decrypt a message sent by jdoe@example.com, the domain example.com must not be configured in either the routing settings or any SMTP profile.
• A summary of the signing/encryption result is written into the subject line of each email. For example, an email that was correctly signed and encrypted with S/MIME, has '(S/MIME: Signed and encrypted)' appended to the subject line.

Note – Adding a footer to messages already signed or encrypted by an email client (e.g., Microsoft's Outlook or Mozilla's Thunderbird) will break their signature and render them invalid. If you want to create digital signatures on the client side, disable the antivirus check footer option. However, if you do not wish to forgo the privacy and authentication of your email communication and still want to apply a general antivirus check footer, consider using the built-in email encryption feature of Sophos UTM. Email encryption done on the gateway means that the footer is added to the message prior to creating the digital signature, thus leaving the signature intact.