When it comes to securing your organization's email, there are a number of good general guidelines to follow:
Use well-tested security mechanisms. Closed,
proprietary mechanisms are more likely to contain serious flaws and are
harder to fix when those flaws are found.
Reuse
the same mechanisms whenever you can. This helps minimize
administrative complexity and reduces the amount of code that must be
patched to distribute a fix.
Go for as
much coverage for as little effort as you can. You want to reduce the
amount of work you need to do and maximize your bang for the buck.
With these guidelines firmly in mind, we'll start our
discussion of email security by talking about transport security — the
art of securing messages that are in transit or moving from one location
to another, such as from your client to your mailbox server, between
Exchange servers in your organization, or between organizations (whether
or not both are using Exchange).
If you deploy no security measures with Exchange 2010
other than Secure Socket Layer (SSL) and Transport Layer Security
(TLS), you will have done more to ensure transport security for your
organization's message traffic than any other single step you can do.
Exchange 2010 even makes it ridiculously easy for you to do so; the SSL
and TLS protocols are enabled and configured out of the box.
1. SSL: Pick Your Port
Everyone who has used a web browser sometime in the
last five years should be familiar with the basics of what SSL is.
Unfortunately, all most people know is that "it's that little padlock on
some websites." A few more know that SSL has something to do with
digital certificates, although most people don't know what a digital
certificate is in turn. All they know is that SSL is what makes secure
web transfers possible.
Developers through the years have spent a lot of time
and energy developing security protocols. SSL is perhaps the best known
and most popular, in part because it piggybacked on the exploding
success of the World Wide Web. As a result, SSL has become firmly linked
with HTTP — which is a shame, because it can be used to secure just
about any TCP-based protocol. It has, however, gone through multiple
revisions and additions. In fact, SSL version 1 was never actually
released.
SSL v2.0 was developed and released in November 1994
by Netscape Communications. While it incorporated several advanced
features — such as support for per-session negotiation of a number of
specific cryptographic algorithms — and provided a decent level of
security for HTTP sessions, it wasn't perfectly secure. It had several
flaws and weaknesses that left it vulnerable to determined attackers and
allowed the risk of data exposure, including the ability to force
weaker algorithms to be used. At this time, SSL was not an open standard
that was part of the IETF standards process.
Privacy Communication Technology (PCT) v1.0 was
Microsoft's 1995 attempt to do two things: first, fix the weaknesses
present in SSL v2.0; second, either supplant or replace Netscape's
proprietary security protocol with a competitor or, at the very least,
pressure Netscape to open up control of SSL. Although PCT incorporated
several new features, history bears the record of the result: PCT was
never widely adopted and is not used in the modern Web. However, SSL was
revised and the resulting standard was opened up to the IETF standards
process.
SSL v3.0 was released as an IETF draft in November
1996, once again by Netscape. It both addressed most of the weaknesses
in SSL v2.0 and incorporated many features of PCT to strengthen the
overall protocol. Because the standard was released as an Internet
draft, implementers could freely include support for SSL v3.0 in their
code. This version of SSL is still widely used on the Internet today — a
testament to its flexibility and robust design.
2. How SSL Works
Let's dive beneath the hood and take a deeper look at how SSL works. We'll need the following objects:
A Web Server
Although SSL can be used to protect a variety of protocols, we'll use HTTP for our example.
An X.509v3 Digital Certificate for the Web Server
We haven't talked about what digital certificates are in depth. For the time being, just
know that a digital certificate is essentially a document that consists
of multiple properties and values. Some of the important properties and
values we'll look at include:
The SubjectName property describes the hostname associated with the certificate. In our example, the hostname is www.somorita.com.
The
SubjectAlternateName property is optional, and describes one or more
hostnames that are also associated with the certificate. For our
example, we won't use this property.
The
Thumbprint property provides a cryptographic hash that is used to
uniquely identify a certificate. When you have multiple certificates on
your Exchange server, this can be a valuable shortcut for uniquely
identifying which one you want to work with. For our example, this
property isn't important.
The
PublicKey property describes a cryptographic public key that is
associated with the certificate. The public key is intended for use by
any remote server (or user). Data that is encrypted using the public key
cannot be decrypted using that key.
The
Private Key is not part of the certificate but is nonetheless
important. When the certificate is installed on the server and is
intended for the server to use for authentication, an associated private
key is securely stored on the server. The private key is never
associated with the certificate or stored as one of the server
properties. Our example certificate has a public key and private key;
the specific values are unimportant.
The
certificate also contains one or more digital signatures from the
issuing certificate authorities. These signatures are essential to
verify the validity of the certificate. Without these signatures,
malicious people could easily forge a certificate. However, the chain of
trust is only as strong as the amount of security around the issuing
certificates of the upstream certificate authorities. Our example
certificate has a signature from the enterprise root CA installed on ca.somorita.com.
The
certificate may also contain other metadata fields that define
information such as the length of time the certificate is valid, the
valid uses for the certificate, and other information. Not all of these
fields are required for every certificate, but flexibility with
certificates makes the certificates a generic useful tool rather than a
specialized tool for one or two narrow uses. For our example, these
aren't important.
A Web Client
Typically a web browser, although it could be any
program that speaks HTTP. In this example, you can imagine we're using
whichever browser you're happy with.
A URL for the Client to Contact
This URL contains the hostname of the server. The
client will resolve this hostname back to an IP address through the
usual mechanisms. Our example URL is https://www.somorita.com/ — which specifies the HTTPS (HTTP + SSL) protocol.
A Dedicated TCP Port for the Server to Listen for HTTP and SSL Traffic
Traditionally, HTTP is on TCP port 80 while HTTPS is on TCP port 443.
With this configuration in mind, let's look at Figure 5.1. What we see is a multistep process. It looks complicated, but it's not.
1. The client contacts the www.somorita.com
server on TCP port 443. Since the browser knows that the URL protocol
is HTTPS, it knows it must first negotiate the SSL layer and sends the ClientHello
message. This message includes several important pieces of information,
such as the highest SSL protocol version the client supports, a list of
cipher suites, a list of supported compression methods, and a random
number.
2. The server responds with the ServerHello message. Based on the information contained in the ClientHello,
the server can pick which protocol version to use (typically the
highest version mutually supported). This allows backward compatibility.
The ServerHello message tells the
client which protocol version was chosen, which cipher suite will be
used (again, the most secure suite supported by both sides), the chosen
compression method, and the server's random number. This message may
also contain a session ID, which allows the client to later establish
additional connections to the server and participate in the existing SSL
session without having to perform the associated re-negotiation.
3. Depending on how it is configured and which cipher suite was chosen, the server will send either the ServerCertificate message, which contains the entire digital certificate, or the ServerKeyExchange message, which contains a public key used by those cipher suites that don't use a full digital certificate.
4. If the server is configured to require client authentication using digital certificates, it sends a ClientCertificate request message. This is an optional step.
5. The server sends the ServerHelloDone message. This indicates that it has completed its portion of the SSL handshake negotiation process.
6. The first client response is optional. If it received a ClientCertificate request, it responds with the corresponding ClientCertificate message containing its digital certificate and public key.
7.
The client examines the digital certificate presented by the server and
validates it. The specifics of how that validation is performed depend
on the particular client application and configuration, but it typically
includes validating the certificate metadata, such as the expiration
date; the digital signatures of the issuing CAs; and whether the
certificate has been revoked using the CA's certificate revocation list
(CRL).
8. At this point, the client generates a master secret key that is based on random numbers generated during the ClientHello and ServerHello.
9. In any event, the client then sends the ClientKeyExchange
message. This message contains specific information required by the
selected cipher suite; a secret value, a public key, or even no value at
all. The secret key will be encrypted with the server's public key so
that it is protected when it is sent back.
10.
The client and server now need to establish a shared secret. They can't
just pass it over the wire — communications to this point are in the
clear and could be intercepted. Instead, they use the random numbers and
other cryptographic elements previously passed in steps 1, 2, and 7 to
compute a common valued called the master secret.
This master secret cannot be validated by an eavesdropper, which
doesn't possess the private key data necessary to decrypt specific
values. Using private key encryption would be slower and more
CPU-intensive than using a symmetric key cipher, so the server and
client both use the master secret to generate the session key block. This key will be used for the actual session encryption algorithm.
11. The client sends the ChangeCipherSpec
message to the server. This signals the server that all further client
communications will use the selected cipher suite, encrypted with the
mutually generated session key block.
12. The client sends a final Finished message. This message is authenticated and encrypted, so only the server can decrypt it and respond appropriately.
13. The server now responds to the encrypted Finished message from the client with its own ChangeCipherSpec message. This signals that the server is also switching to authenticated, encrypted communication.
14. The server sends its final Finished
message. Again, this message is authenticated and encrypted, so the
client can trust it is actually the server (and not some
man-in-the-middle attacker) that has sent the message.
At this point, the SSL handshake is complete. All
further application traffic sent over this SSL session will be encrypted
and authenticated according to the parameters established during the
handshake.
So that's how SSL works, and it works well enough to
be the backbone of our entire modern web-based commerce system. However,
SSL v3.0 does have drawbacks:
As we said before, each SSL handshake picks a
cipher suite from the list of suites mutually supported by the client
and server. These cipher suites allow an almost modular support for a
variety of special-purpose cryptographic algorithms, each one
specialized for a specific use and strength. Each organization can then
prevent the use of any specific algorithm without crippling the SSL
protocol as a whole. However, using a poor or weak cipher can result in
an SSL that can be easily broken. Many of the algorithms included in SSL
v3.0 are now considered cryptographically obsolete, or at least only
suitable for use in conjunction with newer algorithms that are not
supported by the SSL protocol.
The
certificate private key lengths and cryptographic algorithm key lengths
become an important factor. Longer keys take longer to generate and
process but provide greater security, because it makes it harder for an
attacker to brute-force or mathematically break the key. With modern
computer resources, older 40-bit keys should be avoided and SSL should
always be configured to require 128 bits unless otherwise required.
Additionally, new certificates should be at least 1024 bits, and you
should seriously consider 2048 bits or higher.
Certificate
validation is a huge part of SSL. Depending on your application, some
very strict measures can be taken to validate not just the server
certificate, but also the entire certificate chain. Typically, each
server that hosts the certificate (including any reverse proxies or
firewalls that terminate the SSL session) should be configured with the
appropriate intermediate CA and root CA certificates as well. As part of
the SSL negotiation, the server can pass intermediate certificates in
the signing chain on to the client, allowing the client to validate the
chain as long as it trusts the root CA certificate. The trick is to pick
a CA that has appropriate safeguards for validating the identity of the
entity requesting the certificate.
Traditionally,
SSL required a separate IP address for every hostname. With wildcard
certificates and certificates that make use of the Subject Alternate
Name (SAN) property, this restriction is somewhat eased. However, if
you're trying to offer both secured and nonse-cured versions of the same
protocol, you must do so over two separate ports. SSL cannot
discriminate between an incoming connection that requires a secure
tunnel and those that do not; it's all or nothing.
If you are ever trying to troubleshoot protocol
problems in your Exchange organization, and that protocol uses SSL or
TLS, the very first thing that you should do is use a browser to connect
to the appropriate resource. Modern browsers will generate warnings
about the SSL session when there is an issue with the certificate, such
as a name mismatch, an expired certificate, a revoked certificate, or a
certificate signed by a CA whom you do not trust. When you can connect
without errors, you know that you've got your certificate issues worked
out and can move on to the next stage.
Often, clients like Outlook or other
Exchange servers will not tell you exactly what is wrong with your
certificate configuration without a lot of extra diagnostic logging.
Simply knowing how to use a browser can be a lot faster and easier.
