3. Enter Transport Layer Security
As SSL began to be widely adopted and the nature of
laws of cryptographic exports changed how computer science was able to
research and publish new algorithms, the IETF pushed forward with
continuing to improve SSL into a fully open standard. Their result,
published in January 1999 as RFC 2246, introduced Transport Layer
Security (TLS) v1.0. The current version of TLS, v1.2, is described by
RFC 5246.
While TLS is clearly based on SSL, it is not meant to
be 100 percent backward compatible, although compatibility concerns
were minimized by including an SSL v3.0 fallback mode. However, the IETF
replaced some internal calculations with stronger variants, improved
the cipher suites, and made other housekeeping changes. These details
are minor, though, and TLS and SSL are generally (as protocols)
considered equally strong. TLS can be configured to be stronger because
it supports stronger component algorithms in its supported cipher suites
— but that's a reflection on those algorithms, not on TLS as a whole.
The biggest difference between SSL and TLS is that
the latter is specifically designed to be invoked in-band in a nonsecure
protocol connection, allowing the client and server to establish a
protocol session, create the secure tunnel, and then move on with their
protocol session. This difference has one very real benefit that has
made TLS of great benefit to SMTP in particular: it allows a single
well-known listener at TCP port 25 to offer both nonsecure SMTP sessions
from non-TLS SMTP mailers as well as secure SMTP + TLS sessions from
servers that are configured to take advantage of the additional
security. If some error such as certificate validation prevents the
secure tunnel from being established, the client and server applications
can continue to use the existing session, albeit with whatever
limitations each has locally configured. As an example, an SMTP mailer
can offer strong authentication options such as NTLM to every
connection, but restrict the offering of Basic text authentication to
only those machines that first establish TLS.
Let's take a look at this in action with this sample Exchange SMTP protocol log:
{The client connects to the server}
01 S: 220 ex2010.somorita.com ESMTP ready at Sun, 31 May 2009 22:37:28 -0700
C: EHLO desktop.somorita.com
S: 250-ex2010.somorita.com Hello desktop.somorita.com
S: 250-SIZE
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
02 S: 250-STARTTLS
S: 250-X-ANONYMOUSTLS
03 S: 250-AUTH NTLM
S: 250-X-EXPS GSSAPI NTLM
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-CHUNKING
S: 250-XEXCH50
S: 250 XRDST
04 C: STARTTLS
S: 250 2.0.0 Ready to start TLS
05 C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
06 S: 220 ex2010.somorita.com ESMTP ready at Sun, 31 May 2009 22:37:30 -0700
C: EHLO desktop.somorita.com
S: 250-ex2010.somorita.com Hello desktop.somorita.com
S: 250-SIZE
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-X-ANONYMOUSTLS
07 S: 250-AUTH NTLM LOGIN PLAIN
S: 250-X-EXPS GSSAPI NTLM
S: 250-8BITMIME
S: 250-AUTH NTLM LOGIN PLAIN
S: 250-X-EXPS GSSAPI NTLM
S: 250-BINARYMIME
S: 250-CHUNKING
S: 250-XEXCH50S: 250 XRDST
{The client continues the session}
There are seven key points of note in this conversation:
The server sends an initial greeting from the server to the client; the client responds with the EHLO response.
The server advertises its support for the STARTTLS verb, which allows the client to begin the TLS handshake.
The
server is also advertising SMTP AUTH. In this case, it only offers the
NTLM authentication mechanism. This is prudent security; it prevents the
transmission of user credentials in clear text over a nonsecured
connection.
The
client begins the TLS negotiation process and the server responds with
the status code, indicating that it will allow the negotiation to begin.
The client and server walk through the TLS negotiation process (refer to Figure 5.1 if you're rusty on the overall details).
The
server accepts the results and resets the SMTP session. This is
explicitly mandated by the STARTTLS RFC (RFC 2487); the only state
information the client and server are allowed to keep after the TLS
session is established is the information gathered during the TLS
handshake. Any knowledge of SMTP verbs offered or hostnames used is
explicitly forbidden to be kept. The client must effectively begin the
SMTP session again.
This
time, however, the results are a little different. First, STARTTLS is
not offered again — that would be redundant and could cause some
interesting bugs and denial-of-service conditions. The interesting part,
though, is that this time, SMTP AUTH is also offering Basic
authentication methods. Because the connection is now secure, the server
configuration permits the use of this less secure authentication
technique.
|
Windows Server 2008 made some changes to the default
cipher suites that it supports and the order in which it offers these
ciphers. For the most part, these changes are good — they introduce
newer, stronger algorithms, such as AES and SHA-1, and retire older,
nonsecure algorithms, such as RC4 and MD5. In some rare cases, you may
find that these changes prohibit interoperability with external systems
and programs.
These cipher suites specify three sets of algorithms: a key exchange algorithm to transfer the public key information needed to ensure authenticity, a streaming cipher that allows encryption of the session data using the derived symmetric key, and a message digest algorithm that provides a secure cryptographic hash function.
In Windows Server 2003, this is the default list of cipher suites:
TLS_RSA_WITH_RC4_128_MD5 (RSA certificate key exchange, RC4 streaming session
cipher with 128-bit key, and 128-bit MD5 HMAC; a safe, legacy choice of
protocols, although definitely aging in today's environment)
TLS_RSA_WITH_RC4_128_SHA (RSA certificate key exchange, RC4 streaming session
cipher with 128-bit key, and 160-bit SHA-1 HMAC; a bit stronger than the above,
thanks to SHA-1 being not quite as brittle as MD5 yet)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (you can work out the rest)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
In Windows Server 2008, you get the following default configuration (new suites are boldfaced):
TLS_RSA_WITH_AES_128_CBC_SHA (Using AES 128-bit as a CBC session cipher)
TLS_RSA_WITH_AES_256_CBC_SHA (Using AES 256-bit as a CBC session cipher)
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 (AES 128-bit, SHA 256-bit)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384(AES 128-bit, SHA 384-bit)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521(AES 128-bit, SHA 521-bit)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256(AES 256-bit, SHA 256-bit)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384(AES 256-bit, SHA 384-bit)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521(AES 256-bit, SHA 521-bit)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 (you can work out the rest)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5)
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
|
Note that key lengths are not an Exchange-specific
issue; they are controlled by the underlying operating system. If you
have Exchange 2007 servers deployed on Windows 2008, they're benefiting
from the same changes and can be affected by the same issue.
4. Opportunistic TLS
We hammered home the point in the previous section
about how the certificates you use must be trusted and validated. Now,
normally in Exchange and Outlook, this validation is pretty strict.
Sometimes neither Exchange nor Outlook will give you any nice errors if
validation fails — they just won't work. However, when Exchange 2010
(and Exchange 2007, while we're at it) is acting as an SMTP client and
connecting to another SMTP server, Exchange performs no certificate
validation. Exchange's SMTP client (the Send connectors, if you like)
will always accept whatever certificate the server offers during TLS handshakes.
Now, your initial reaction may be something like
"You've got to be kidding! That's so unse-cure!" Well, yes and no. It's
arguably less secure than the ideal case of being and enforcing
certification validation. However, one of the most common reasons why
certificate validation fails is that the server is using a CA the client
doesn't trust. This is reasonably common; many organizations deploy
certificates using an internal PKI. Their clients are given the correct
root CA certificates; all other systems won't validate it and will use
regular SMTP. No biggie, right? In this case, we actually gain security by using the certificate anyway — we'll take advantage of the opportunity to encrypt the session.
But what if there's a genuine spoofed or
"self-signed" certificate in place? Here's the thinking: so what?
Consider the options. You either refuse to use the certificate (and send
the message in the clear where anyone can be listening to it), or you
use the untrusted certificate and send the message anyway — and only
expose the message to the person who provided the untrusted certificate.
If they have the level of access to be able to create and install an
untrusted certificate, they have the level of access to get
administrator access to the server and intercept your communications
anyway.
When an SMTP client or server goes ahead and allows a
TLS session to be initiated even if the certificate is untrusted, this
is called opportunistic TLS. If the
remote system offers TLS, the client will then try to negotiate with the
server to use TLS without being specifically configured to. This is a
direct contrast to legacy Exchange (2000 or 2003) behavior, which only
used TLS when configured to (and then only
used TLS). The benefit here is that the certificates on the Hub
Transport server do not have to be trusted in order to use TLS and the
SMTP data transfer between your Exchange Hub Transport server and a
remote SMTP server that supports opportunistic TLS will be encrypted.
5. Domain Security
Opportunistic TLS gives you the ability to
automatically encrypt the SMTP message flow between an SMTP client and
an SMTP server that supports opportunistic TLS, but without any type of
certificate validation. This gives you an additional level of security
when email is being sent between your servers and the Internet. However,
as we pointed out in the previous section, there is no validation of
the sender's certificate (or even yours).
The Domain Security
feature allows you to configure one or more remote domains on the
Internet (or your intranet) for which you want a secure SMTP connection,
and you also want to validate that the connection did indeed come from
one of their mail servers. Domain Security requires that the
certificates that you are using as well as the remote systems be
trusted.
Both you and the administrator of the remote system
have to configure the transport configuration's
TLSReceiveDomainSecureList and TLSSendDomainSecureList properties for
Exchange 2010 server (or Exchange 2007 server). Both organizations must
be using Exchange Server 2007 or 2010, and those servers must be the
servers that both send and receive email. You cannot go through a
third-party message hygiene system and use Domain Security. Exchange
Server (a Hub Transport or an Edge Transport) must be the source server
as well as the target end-point.
If both the sender's system as well as the
recipient's system are configured to use Domain Security and if the
certificates on both sides are trusted, the recipient of messages from
the trusted remote domain will see a special icon on the message in
Outlook 2007 or 2010 that indicates the message was received from a
trusted source.
