Securing Email Part Three – Client to Client

TopSecretAttachmentThanks for sticking with us, and welcome to part three of this series on securing email. In part one we introduced the challenge, and three influences; compliance, technology, and support. And in part two, we looked at SMTP/TLS and routing SMTP over a VPN for server side solutions. In this final part, we’re going to look at client side solutions to ensure we are securing our email from sender to recipient.

There are two standard ways to do this. Both utilise the services of a PKI, and will require client side configurations. As such we may also find that we need to work with yet another part of the IT department; our desktop support team. They own the desktops and will likely be responsible for the client side configuration necessary with either of these solutions.

When securing email using client to client solutions, we may find this to be the most challenging approach for a number of reasons. We will need to ‘touch’ the clients, and we will need to ensure that we are implementing a solution that is compatible with the recipient systems. On the server side, we can split up our SMTP exchanges, sending some out to the Internet in the clear, others over a VPN, and still others using SMTP/TLS. When working with client side solutions, we need to make sure that what we implement on our clients is the same as what our partner organisation has implemented on their clients. If we have two partner organisations where one chose S/MIME and the other went with PGP, then we may need to purchase both for all the clients that must communicate with both partners.

S/MIME

Addressed in RFC 5751, S/MIME is designed as an end to end encryption mechanism for email, using PKI encryption with certificates obtained from a certificate authority.

Pros:

  • S/MIME allows for digital signing, encryption, non-repudiation, and key escrow to prevent data loss.
  • Can be used to protect emails between internal users as well.
  • Data is protected from the original client through to the intended recipient, and cannot be viewed on the internal network or on any intermediate server.
  • SMTP traffic between servers remains in the clear, so protocol messages can be seen for troubleshooting issues without compromising the integrity of the email contents.

Cons:

  • Each user’s mail client must be configured to support S/MIME.
  • To support both non-repudiation and key escrow, each user must have two different key pairs.
  • Before a client can send someone an encrypted email, they must obtain the addressee’s certificate/public key.
  • Most webmail applications (a critical need for many clients) cannot support S/MIME.
  • Anti-malware and content screening cannot scan the contents of an S/MIME encrypted email. Exceptions must be configured to allow mail to pass uninspected, and you must accept the risk that such email may contain malicious code or content that violates policy.

PGP

PGP and its compatible GPG, uses key pairs to provide encryption and signing of email messages (and of files.) There are several open source products as well as commercial ones available for many common email clients.

Pros:

  • PGP allows for digital signing, encryption, and non-repudiation.
  • Can be used to protect emails between internal users as well.
  • Data is protected from the original client through to the intended recipient, and cannot be viewed on the internal network or on any intermediate server.
  • SMTP traffic between servers remains in the clear, so protocol messages can be seen for troubleshooting issues without compromising the integrity of the email contents.
  • Certificates are not required.
  • Several PGP key servers exist to facilitate key exchange between users.

Cons:

  • Each user’s mail client must be configured to support PGP.
  • To send an encrypted mail to a recipient, you must obtain their public key. Without a certificate authority to act as a trusted third party, you must arrange to obtain that key through a method you are willing to trust.
  • Commercial products can be very costly at the enterprise level.
  • Most webmail applications (a critical need for many clients) cannot support PGP.
  • Anti-malware and content screening cannot scan the contents of a PGP encrypted email. Exceptions must be configured to allow mail to pass uninspected, and you must accept the risk that such email may contain malicious code or content that violates policy.

With either solution, you can securely send email between users without concern for any unauthorised users viewing the contents of the email; even your email system administrators. If this is a requirement for your organisation, then either of these solutions can help you to meet this requirement. Look at both, discuss what solutions may be in place with your existing partners, and determine which has the best fit for your organisation.

Written by Ed Fisher

An InfoTech professional, aficionado of capsaicin, and Coffea canephora (but not together,) I’ve been getting my geek on full-time since 1993, and have worked with information technology in some capacity since 1986. Stated simply, if you need to get information securely from a to b, I’m your guy. I’m like "The Transporter," but for data, and without the car. And with a little more hair.

2 Comments

  1. Serkan Varoglu · September 29, 2010

    Thanks for this great series about Securing Email.
    I enjoyed reading it.

  2. Ed Fisher · February 17, 2011

    Hi Serkan,
    Great to see you at another of the blogs I am on. Folks, Serkan’s Exchange blog is a great source for information too.
    http://get-mailbox.org/

Leave A Reply