Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

9.7. A Brief Introduction to Email Encryption

Encrypting your email from end to end is the very
best defense against eavesdropping attacks; encrypting it and signing
it is also a powerful defense against identity theft. However,
because this book is about bastion-server security, and since email
encryption is in most respects much more of a client/local
application than a "back-office"
application, I'm not going to go very far in depth
on this topic. (The extent to which it does
involve backend services, e.g., in Public Key Infrastructures, is
outside the scope of this book.) There are two predominant email encryption technologies in use
nowadays, PGP and
S/MIME. Both are
end-to-end solutions (end users do all the encrypting and decrypting,
with servers involved only in key distribution) And both are based on
open standards. However, neither PGP nor S/MIME has achieved much
popularity with less technical or nontechnical users. The ugly
reality is that email encryption as we know it places a much higher
burden of skill and knowledge on end users than, say, SSL does with
web encryption.

That's because most SSL sessions on the Internet
are, in real terms, "anonymously"
encrypted. If I buy something from an online retailer, I may or may
not care whether the retailer's secure web server
presents me with an SSL certificate with a valid signature; the
retailer absolutely does not care about whether
my web browser even has a certificate. My
browser and the server will happily build an encrypted session
between each other without being terribly certain that the other
party is who they say they are.^[3] So in most real-world SSL transactions,
there's no authentication.

^[3] Yes, the server
always presents the client with a certificate, but unfortunately,
most users don't hesitate to accept any certificate
presented by an authentic-looking web
sitethat's what I mean by
"anonymous, in real terms." Also, I
may have a "customer account" with
the retailer and be asked to type in a username and password before I
can, e.g., view my account information. But the underlying encryption
mechanism itself, SSL, has even more powerful authentication features
that, for a variety of reasons, are seldom implemented.
That's what I mean by "anonymous
encryption." See Chapter 5 for
more information about client-certificate authentication.

And that's fine, in most of those cases. But email
encryption is another matter altogether: if you encrypt something for
"your friend's eyes
only," you care very much whether the key
you're using to encrypt the message truly is your
friend's: you don't want anybody
else to be able to read the message. Your friend probably cares
equally strongly whether it was actually you who sent the message and
not some imposter.

Thus, email encryption isn't just about encryption;
it's about identity
management. (In fact, I'll go
so far as to say that the encryption itself is the easy part.) Modern
email encryption systems have yet to present users with simple and
intuitive mechanisms for keeping track of the encryption credentials
(keys) of everyone they need to communicate with, managing their own
credentials, etc. It's an inherently complex and
still somewhat immature technology.

Still, this stuff does work, and
it's worth the effort it takes to deploy and use it.

PGP, short for "Pretty Good
Privacy," is the older and more popular of the two
technologies. The other, S/MIME, is rapidly gaining ground, thanks at
least in part to the fact that support for it is built into Microsoft
Exchange and Outlook.

9.7.1. PGP and GnuPG

The brainchild of hacker saint Phil Zimmerman, PGP
was the first email encryption tool to gain anything resembling
widespread popularity, and to this day, it is used all over the
world. PGP exists in both free and commercial versions, but over its
long history it has been, at various times, illegal for export from
the U.S.; free for noncommercial use only; closed source; and in
limbo (neither being sold as a commercial product or available for
use in a free version).

Happily, PGP is now back to being actively maintained both as a
commercial product and in a free-for-noncommercial-use version (see
http://www.pgp.com/products/freewarel for
more information about PGP Freeware). However, for all of the reasons
I just listed, even the ones that no longer apply, many people have
switched from PGP to a 100% free and open source alternative: the GNU
Privacy Guard, a.k.a. GnuPG (http://gnupg.org).

GnuPG is completely compliant with the OpenPGP protocol that PGP
uses, but unlike PGP, GnuPG has always been a purely noncommercial
project. It also intentionally lacks support for the patented IDEA
algorithm, which makes GnuPG less
"encumbered" (legally speaking)
than even PGP Freeware. The biggest strike against GnuPG is that
it's taken a little longer for the open source
community to develop complete and stable GUI tools for using GnuPG;
until fairly recently, GnuPG has been very command-line intensive.
(The GnuPG web site, however, has links to numerous
"GnuPG Frontends" for various
platforms, some of which are now quite mature and useful.) Since this is only an overview of email encryption,
I'll stop short of a detailed explanation of how PGP
and GnuPG work, or how to install and use them. However,
there's one more PGP/GnuPG concept worth discussing
here: the Web of Trust.

With any cryptosystem, key distribution is a major concern: how do
the participants in a given transaction exchange encryption keys?
This is a huge problem with symmetric
encryption mechanisms, in which each side must
use exactly the same key and in which all keys must be kept secret
from outsiders. You might think that it's a much
simpler problem with public-key cryptosystems such as OpenPGP and
S/MIME, in which every user has a public key that can be freely
distributed.

However, although you don't need to protect a public
key from eavesdroppers, you do need to provide people with a reason
to believe the key is truly yours and wasn't created
by an imposter. Put another way, if a public key can show up
anywhere, it becomes that much harder to verify its
origin.

For this reason, PGP and GnuPG users participate in what is known as
the Web of Trust. The idea is simple: if people cryptographically
sign each other's keys, and if each
person's key has been signed by people whose keys
have in turn been signed by other people, then at some point it
becomes likely that any given key you come across has either been
signed by the key of someone you trust or by a key that has itself
been signed by the key of someone you trust. It's
really just a variation of the concept of "six
degrees of separation." For example, suppose Bob knows and trusts Ted, and therefore Bob
cryptographically signs Ted's public key. Suppose
further that I don't know Ted, but I do know Bob. If
I see that Ted's key includes a valid signature from
Bob, I can safely conclude that trustworthy Bob vouches for the
authenticity of Ted's key.

Suppose Ted uses his key to sign Alice's key, and
that I know neither Ted nor Alice. If I validate
Ted's signature on Alice's key, I
can assume that Ted vouches for that key's
authenticity. However, I don't know or trust Ted, so
I examine his key: it was signed by Bob, whom I do trust. Therefore,
although I don't trust Alice's key
as much as I do Bob's, I can still trust it more
than if it had no signatures at all.

Note the absence of any centralized source of
trust: the Web of Trust was designed to be
decentralized. This is utterly consistent with
the somewhat anarchic mindset with which PGP was created; one of
Zimmerman's design goals was to make it
difficult for governments and other authorities
to control PGP's use and proliferation.
Unfortunately, the Web of Trust has not worked terribly well in
practice: few PGP/GnuPGP users are in the habit of signing other
people's keys.

9.7.2. S/MIME

In a nutshell, S/MIME
is simply a standard for using X.509 digital certificates for
email encryption. Throughout the book we've been
using OpenSSL to create server certificates for various applications,
but in fact, certificates are just as useful for individual users as
they are for server daemons.

Unlike PGP and GnuPG, which have always been standalone applications
in their own right and have required plug-ins or other interfaces to
work with actual email software clients, S/MIME is natively supported
by Netscape Communicator, Microsoft Outlook, and the other email
packages it works with. Furthermore, recent versions of Microsoft
Exchange make it especially easy to include users'
digital certificates in their Exchange profiles; for this reason,
S/MIME is rapidly gaining ground in corporate settings.

Besides being supported by popular applications, S/MIME has another
important advantage: centralized key signing and management, thanks
to its X.509 pedigree. Key distribution in S/MIME environments is
generally handled via LDAP, which is the same protocol customarily
used on PGP key servers. But whereas trust in PGP/GnuPG scenarios is
generally decentralized, in S/MIME environments, it is usually
centralized with an organization's Certificate
Authority.

Technically, there's nothing to stop you from
running a PGP key server on which every user key must first be signed
by a single "administrative" or
"root" key of some kind, but that
wasn't the way PGP was designed to work. Since
S/MIME is really just an extension of X.509, it works well within the
standard PKI model of highly centralized trust management
("trust no certificate that hasn't
been signed by the CA").

9.7.3. Which Should You Use?

Deploying email encryption to any organization is a nontrivial
undertaking, and no matter which system you choose (OpenPGP-based or
S/MIME, commercial or open source), you will need to determine your
organization's real security requirements, its
stomach for complexity, and the best fit for your existing
infrastructure and software environment. You'll also
need to plan and budget for a major user-education initiative.

Having said that, I think it's safe to say that
Exchange and Netscape shops will find S/MIME to be the obvious
choice, and PGP or GnuPG will be the best choice if your users need
to routinely exchange encrypted email with people outside your
organization.