W07 Exchange Clients Security

Module 7: Exchange Clients and Security Contents Overview

1

Lesson 1: Accessing Exchange 2003 Remotely

2

Lesson 2: Cryptography Concepts

8

Lesson 3: Secure Sockets Layer (SSL)

26

Lesson 4: Signing and Sealing E-mail (S/MIME)

32

Review

40

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2005 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows 2000, Active Directory, ActiveX, BackOffice, FrontPage, Hotmail, Jscript, MSN, NetMeeting, Outlook, PowerPoint, SQL Server, Visual Studio, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States, and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Module 7: Exchange Clients and Security

1

Overview

This module will look at the different ways that users can remotely access their Microsoft® Exchange mailbox securely. Remote access typically means accessing over the Internet or other form of public network. The different security technologies and concepts that relate to e-mail access will be discussed.

2

Module 7: Exchange Clients and Security

Lesson 1: Accessing Exchange 2003 Remotely

This section will list the different clients that can be used to access Microsoft® Exchange Server 2003 data remotely.

Module 7: Exchange Clients and Security

3

Outlook and ISA RPC Filter

Microsoft® Internet Security and Acceleration (ISA) Server's Remote Procedure Call Protocol (RPC) application filter enables secure communication between Microsoft® Outlook® clients and an Exchange Server over the Internet. The RPC application filter protects RPC communication over the Internet by identifying which specific RPC interface is requested and allowing only calls to those interfaces. Furthermore, the RPC application filter opens ports dynamically, meaning that the communication is allowed only when it is specifically requested. In addition, Exchange Server communicates with Outlook clients using a lightweight User Datagram Protocol (UDP)-based protocol. The RPC application filter also processes new mail notification as follows: when an Outlook client logs on to an Exchange Server, it registers to receive new mail notifications by passing through RPC a port number on which it will listen. When new mail arrives, the Exchange Server sends a single UDP packet to the port. To allow this type of notification, standard firewalls must typically open a wide range of ports. With the RPC application filter enabled, ISA Server intercepts registration for new mail and dynamically opens only the necessary ports. Thus, Exchange Server publishing is more secure with the ISA Server firewall. Note The RPC Filter is part of ISA Feature Pack 1. How the RPC Application Filter Works

In an Exchange Server/Outlook client scenario, the RPC application filter works as follows: 1. The Outlook client issues request over Port 135 (TCP) through ISA Server to the Exchange Server, to find the service port number associated with the Exchange RPC universal unique identifier (UUID).

4

Module 7: Exchange Clients and Security

2. The Exchange Server sends a response back through the ISA Server to the Outlook client, with a port number on which the client can communicate. The connection to Port 135/TCP is then closed. 3. ISA Server uses the RPC application filter to capture this information and maintains it in a table. 4. ISA Server allocates a new port on the ISA Server itself and changes the response that it sends to the Outlook client to reflect this change. This information is also maintained in the table. 5. The Outlook client issues a request seemingly to the Exchange Server, but actually to the new port on the ISA Server. The ISA Server then sends the packet to the Exchange Server. Only communication over this port is allowed. Forcing DSProxy

When the Outlook client connects to an Exchange Server, the Exchange Server instructs the Outlook client to communicate directly with an Active Directory® Global Catalog for address book look ups. In the publishing scenarios described in this paper, this direct communication will not function properly if the Outlook client is on the Internet, while the Global Catalog is on the corporate Intranet. This is because ISA Server does not publish any Global Catalog server. Microsoft® Exchange 2000 Server and Exchange 2003, however, have the ability to act as a directory service proxy for older clients, which cannot connect to a global catalog. This service is called DSProxy. Newer Outlook clients (Microsoft® Outlook® 2000 and later) use the Referral (RFR) service by default so that they are referred to a global catalog for direct communication. It is possible to disable the Referral service so that all Outlook clients will use DSProxy. This means that Outlook clients will no longer attempt to connect to global catalogs directly, but will submit all their address book look ups via the Exchange server. To achieve this, implement the following registry change on the Exchange server: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

Forcing RPC Encryption

Value:

No RFR Service (DWORD)

Data:

1 (disable referral to global catalog)

Outlook clients can select to use RPC encryption to the server. This will use the RPC encryption available on the operating system to encrypt all RPC communication between Outlook and Exchange (usually 128 bit). ISA Feature Pack 1 as the ability to reject any Outlook traffic which does not have encryption enabled. This is achieved by the following registry change on the ISA server: HKLM\Software\Microsoft\RPC\PluginRPC Value:

MinimumAuthenticationLevel (DWORD)

Data:

2 (force RPC encryption)

Module 7: Exchange Clients and Security

Outlook 2003 RPC Over HTTPS

Outlook 2003 has the ability to make an RPC connection to an Exchange server using a HTTPS (Secure Sockets Layer [SSL]) tunnel. In effect, all the RPC traffic is encapsulated into HTTPS traffic and sent to you Exchange server via an RPC Proxy server. (See the Outlook 2003 module for more details.) This feature gives users the ability to have the full blown features of Outlook with the network flexibility of Outlook Web Access. For many users, this feature has meant that the no loner use Outlook Web Access for accessing their e-mail over the Internet. Because HTTPS is used, then all the RPC communication is protected by 128bit encryption, and is therefore secure.

5

6

Module 7: Exchange Clients and Security

Outlook Web Access

Outlook Web Access has been the main method for users gaining access to their Exchange mailbox over the Internet. Outlook Web Access has been continuously enhanced since it first appeared with Microsoft® Exchange 5.0. Exchange 2003 has probably made the biggest set of improvements to date, with many new features which elevate it from a basic email client to more advanced collaboration software. Outlook Web Access can use (and enforce) HTTPS access, and is therefore completely secure.

Module 7: Exchange Clients and Security

POP3 and IMAP4

Exchange has supported POP3 and IMAP4 since Exchange 5.0 and Microsoft® Exchange 5.5 respectively. Both these protocols support SSL for securing their communication.

7

8

Module 7: Exchange Clients and Security

Lesson 2: Cryptography Concepts

This section will cover the fundamental concepts of cryptography from which most security technology (e.g. SSL, Signatures, S/MIME, etc.) are derived from.

Module 7: Exchange Clients and Security

9

Overview of Cryptography

The security objectives of most applications and communications are simple: „

Hiding Data – You want to ensure that data transmitted (or stored) cannot be ‘seen’ (i.e. is illegible) by unwanted parties.

„

Authentication/Identifying Originator – You may need to be able to identify an entity. For example, someone requesting access to a bank account needs to be identified as the account holder. Used extensively on networked resources such as file shares and -email accounts. As well as identifying an entity such as a user, you may also need to identify the author of a piece of data. For example, if an accounts department receives an email from the CEO authorising large sales invoice, you will need to be 100% sure that the e-mail came from the CEO.

„

Data Verification – As well as identifying the sender of the data you want to make sure that the data itself has not changed (e.g. forgery). For example, the bank receives a request to transfer a sum of money from a customer account to the phone company to pay a bill. As well as the company identifying that the sender is the account holder, it needs to verify that the sum requested is the claimed $10,000 on the request!

„

Non-Repudiation – Sometimes it is necessary to prove that a person sent or authored a piece of data. For example, if a stock broker received an e-mail from a client asking to purchase many shares just before the price crashed down, the client may deny having sent the purchase request. A way is needed to prove that the client actually sent the message. In many cases, contracts made and signed using cryptographic technologies are now seen as totally binding in a court of law.

The fundamental tools required to achieve the above are actually quite simple. In fact only two things are needed to meet these objectives effectively: an Encryption algorithm (known as Ciphers, of which there are two fundamental types) and a hashing algorithm.

10

Module 7: Exchange Clients and Security

From these two tools, most of the security technologies including SSL, S/MIME, Digital Signatures, Certificates, etc. are derived.

Module 7: Exchange Clients and Security

11

Symmetric (Secret Key) Encryption

The starting block of cryptography is Symmetric Key (also known as Secret Key, Single Key or Shared Key) encryption. In symmetric key cryptography, the same key is used for both encryption and decryption. Data encrypted with a symmetric key can only be decrypted with the same symmetric key. How Symmetric Ciphers Work

A key itself is simply a piece data (whose length is measured in bits). A symmetric cipher is a mathematical algorithm which will take a piece of data (e.g. message or packet) and transform it into another piece of data using the key as another input. The transformed data must be completely different to the original data and must be computationally infeasible to transform back to the original data without the original key.

Key Distribution

Symmetric-key cryptography is a straightforward process for a single user encrypting and decrypting files on a standalone computer (e.g. the password protect feature in Microsoft® Word uses symmetric encryption). However, a number of issues arise when two users want to send encrypted messages to each other. They must agree on a shared secret key, and each must trust the other not to divulge the key. When the key is transmitted from one user to another, it must be transmitted in such a way that an adversary cannot intercept and discover it during transmission. For example, Alice wants to send Bob an encrypted email. If she uses symmetric key encryption then Bob must have the same key as Alice. Alice cannot send the key to Bob because a third party may intercept it and use it to decrypt Alice’s messages to Bob.

Symmetric Ciphers

Symmetric Key Cryptography’s main advantage is that the algorithms are computationally relatively simple and therefore, fast to process. Several algorithms have been published with varying key lengths, performance, and security. These include: „

DES – The Data Encryption Standard (DES) algorithm was published in 1977 by the U.S. National Bureau of Standards and uses a 56-bit key (the

12

Module 7: Exchange Clients and Security

key appears to be a 64-bit key, but one bit in each of the 8 bytes is used for odd parity, resulting in 56 bits of usable key).

Key Lengths

„

3DES (Triple DES) – 3DES is a highly secure variant of DES. It is slower in performance than DES because it processes each block three times, using a unique, 56 bit key each time, making the effective length of the key 168 bit.

„

RC2, 3 and 5 – These ciphers were developed by Ron Rivest of RSA Data Security Inc. RC stands for Rivet’s Ciphers. RC5 is the latest version of this cipher series. Although RC5 has a variable key size (0 to 2048 bits), it is typically used with a 128-bit key.

The length of the key is measured in bits; e.g. a 40-bit key is equal to 5 bytes. The longer the key, the more permutations it has and therefore, the harder it is to break. A 40-bit key has 240 (1099511627776) permutations. However, the longer the key length, the more processing is required to encrypt (and decrypt) a piece of data. A 56-bit key has 65,536 times more permutations than a 40-bit key. In other words if a brute force hacking algorithm takes one hour to crack a 40-bit key, it will take 65,536 hours (about seven and a half years) to break a 56-bit key. A 128-bit key has 309,485,009,821,345,068,724,781,056 times more combinations than a 40-bit key. So as you can see, 128 bits is MUCH more secure.

Module 7: Exchange Clients and Security

13

Asymmetric (Public/Private Key) Encryption

Asymmetric ciphers involve two keys which are generated together. The keys have the following properties: „

A piece of data encrypted with one key can only be decrypted with the other key. It cannot be decrypted by the key that encrypted it (as in symmetric encryption).

„

Because the two keys are therefore related (generated together mathematically), it must be computationally infeasible to generate one key by having the other.

So to summarize, one key is used to encrypt a piece of data while the other decrypts that data. The two roles are interchangeable between the two keys, e.g. key A can be used to encrypt while key B decrypts, or the other way around. Key Distribution and Public and Private Keys

The main feature of these algorithms is the simplicity of key distribution. Each user would generate a key pair for themselves. One key is made public (i.e. anyone can request it) while the other is kept private (only the user has access to it). This way you can securely send a piece of data to a user by encrypting it with their public key. Only that user can decrypt it because it requires their private key. For example, Alice wants to send Bob a secure message. Bob sends Alice his Public key which Alice uses to encrypt the message with. It does not matter that a third party has access to the Public key since it cannot be used to decrypt the message. The encrypted message is sent to Bob who uses his Private key to decrypt the data. Public keys can be held in a public location, for example in a directory or Global Address List (GAL) so that users can send data to each other easily. The private key must be protected at all costs, because if it is compromised then all encrypted data sent to you can be decrypted with it.

14

Module 7: Exchange Clients and Security

Asymmetric Ciphers

The main disadvantage of Asymmetric ciphers is that the algorithms involved are computationally complex and therefore should not be used to encrypt large volumes of data. In order to make it very difficult to compute the private key from the public key, very large numbers have to be used in defining them. Typically these keys have a bit length of around 1024. Algorithms include: „

Diffie-Hellman – Whitfield Diffie and Martin Hellman are recognized as having introduced the concept of public-key cryptography in 1976. The Diffie-Hellman key agreement protocol allows two entities to establish a secret key without having any prearranged shared secrets between them. The Diffie-Hellman protocol uses public key technology to generate a session key. It is based on using very large prime numbers.

„

RSA – RSA is a patent-protected public-key cryptosystem for encryption and authentication invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman, founders of RSA Data Security, Inc. RSA accepts a variable key-length (between 512 and 4096). In software, RSA is about 100 times slower than DES and in hardware, about 1000 times. RSA is the most widely used method of Asymmetric cryptography.

Later this lesson will examine how public key and symmetric key encryption are combined together to produce a secure and efficient solution.

Module 7: Exchange Clients and Security

15

Lock Box Key Distribution

Although Public key encryption seems to solve the problem of key distribution, it has one major drawback: Asymmetric key algorithms are very complex and require much processing. For example if Alice wants to send Bob a 1 MB financial spreadsheet, a Public key encryption would take a long time to perform, and Bob would spend a lot of time decrypting it. Another problem, more specific to e-mail, is if you want to send a copy of some data (e.g. a mail message) to multiple recipients securely. If you use Public key encryption, then whose public key will you use to encrypt the message? In actuality, you must send a separate copy of the message to each recipient encrypted with that recipient’s public key. This is inefficient in terms of network traffic and storage. Lock Box Solution

A solution using a combination of Asymmetric and Symmetric key encryption solves both the above problems. It works as follows (assume all users have public/private key pair): Alice wants to send Bob a large piece of data. Alice generates a random key and encrypts the message with it using symmetric encryption which is fast and efficient. She then uses Bob’s public key to encrypt the symmetric key and attach it to the message which she sends to Bob. Bob receives a (symmetrically) encrypted message and the key to open that message which is encrypted with his public key. He uses his private key to access the symmetric key, which he uses to decrypt the message itself. In effect Alice is taking the key to the message and locking it with the recipient’s public key, this is called a lock box.

Multiple Recipients

The slide shows a message being sent two both Alice (user A) and Bob (B) without having to generate to copies. The principle is exactly the same as in the above example except that two copies of the symmetric key are attached, each one encrypted with that recipient’s public key. The overhead of the extra keys is much less then if you had to send the message out multiple times.

16

Module 7: Exchange Clients and Security

Hashing Algorithms

Hashing algorithms produce a hash (or digest) of a given piece of data. A hash works on a similar principle to CRC (Cyclic Redundancy Check) or parity but is much more sophisticated. You can think of a hash as a ‘unique’ fingerprint of a given piece of data. A good hashing algorithm should support the following properties for its hashes: „

Small and Fixed Size – Regardless of the size of the data, the hash should be relatively small and be of fixed size. So two messages, one being 10 MB and the other just 1 KB should both produce hashes of 128 bits each (for example).

„

Collision Free – Two pieces of data should always produce two different hashes. It should be almost impossible for two different pieces of data to produce the same hash value.

„

Avalanche Effect – A small change in the data should produce a big change in the hash value. In a good hash algorithm, changing just one bit in the data will change half the bits in the hash. In other words, a small data change has an avalanche effect on the hash value.

Irreversible – Statistically, it should be infeasible to reverse the hashing process and regenerate the message from the hash value, i.e. one-way hash. A hash can be attached to a message before it is sent so that the recipient can verify that the data received is the same data that was sent. For example Alice wants to send Bob a message, and she must ensure that Bob receives the message unmodified (for example, by a noisy network connection). She produces a hash of the message and sends it together with the message. When Bob receives the message, he uses the same algorithm to generate a hash of what he has received. Bob then compares the hash that he generated with the hash that Alice sent him. If the data has not been modified in transit, the two hashes should be identical.

Module 7: Exchange Clients and Security

Hashing (Digest) Algorithms

17

Hashing algorithms in use today include: „

Message Digest (MD2, 4 and 5) – All three algorithms take a variablelength input and return a 128-bit message digest. MD2 is optimized for 8-bit computers. MD4 and MD5 are optimized for 32-bit computers. Developed by Ron Rivest, MD2, MD4, and MD5 are products of RSA Data Security, Inc.

Note MD4 has a flaw which means it is not very collision free, i.e. it is relatively easy to generate two pre-images with the same hash value. MD5 fixes this flaw. „

Secure Hash Algorithm (SHA, SHA-1) – The Secure Hash Algorithm was developed by the National Institute of Standards and Technology (NIST). SHA-1 corrects a flaw in SHA. The algorithm takes a message of less than 264 bits as input, and produces a 160-bit message digest. The SHA-1 algorithms have no known cryptographic attacks, unlike the message digest algorithms described above. It is more resistant to brute force attacks because of the 160-bit digest.

18

Module 7: Exchange Clients and Security

Digital Signatures

A digital signature is used to verify two things about a piece of data:

Creating a Digital Signature

„

Verifies the Sender – Just like a normal signature, a digital signature verifies the sender or author of the data, because only that person can generate this signature.

„

Verifies the authenticity of the data – That is, the data has not been modified since it was signed.

There are two steps involved in creating a digital signature from a message. The first step is to create a hash value from the message. The hash value is often referred to as a message digest. The second step is to encrypt the message digest with the sender’s private key. This encryption step is referred to as signing, and the encryption algorithm is sometimes referred to as a signature algorithm. The message digest is encrypted not for confidentiality, but to provide a means for verifying the integrity and authenticity of the message. The private key is used to encrypt the hash because only the signatory has access to the key; therefore, no one else can forge or reproduce that signature. Why hash the message and encrypt the message digest? Hash functions tend to be faster than signature algorithms, and documents tend to be larger than their hash values. Therefore, it is typical to compute the digital signature to a document on the document’s hash value rather than on the document itself. Signing a message does not alter the message; it simply generates a digital signature string that can either be bundled with the message or transmitted separately.

Digital Signature Example

As an example, suppose Alice wants to send a signed message to Bob. First she applies a hash function to the message to create a message digest. She then

Module 7: Exchange Clients and Security

19

encrypts the message digest with her private signature key to create the digital signature, which she sends to Bob along with the message When he receives the message and signature, Bob decrypts the signature with Alice’s public signature key to recover the message digest. He then hashes the message, using the same hash function that Alice used, and compares the result to the message digest that he recovered from Alice’s signature. If they are equal, he can be confident that the message came from Alice (or from someone in possession of Alice’s private key), and that the contents of the message were not altered after the message was signed.

20

Module 7: Exchange Clients and Security

Certificates

There is one big problem so far when using asymmetric encryption and digital signatures. You assume that a public key that you are using really belongs to who you think it does. For example, say that our bad guy Jack wants to send a message to Bob and make it appear that it is from Alice. He composes the message and creates a hash of it. Jack does not have access to Alice’s private key to sign the hash with. Instead Jack encrypts it with his own private key and gives the message to Bob with a public key claiming to belong to Alice. Bob would use the public key to check the hash and the message would indeed appear to be genuine. In this case Bob’s only defense is a mechanism to tie a public key with a user. This is what certificates are used for. Certificates

A certificate (digital certificate, public-key certificate) is a digital document that attests to the binding of a public key to an entity. The main purpose of a certificate is to generate confidence that the public key contained in the certificate actually belongs to the entity named in the certificate. A certificate contains a public key as well as information including the name of the owner of the public key, their e-mail address, and other information. This information is verified as correct by the issuer of the certificate placing a Digital Signature on the certificate. Issuer’s of certificates are called Certificate Authorities and are discussed on the next slide.

Certificate Types

Certificates are of different types which defines what they can be used for. For example, certificates used by users in their S/MIME clients cannot be used for Web Server authentication and communication (e.g. SSL). The certificate type must be specified when applying for a certificate from the issuer.

X.509 Certificates

The most widely adopted structure and syntax for digital certificates is defined by the International Telecommunications Union in ITU-T Recommendation

Module 7: Exchange Clients and Security

21

X.509, currently in version 3 of this standard. An X.509 certificate consists of the following fields: „

Version

„

Serial number

„

Signature algorithm ID

„

Issuer name

„

Validity period

„

Subject (user) name

„

Subject public key information

„

Issuer unique identifier (X.509 versions 2 and 3 only)

„

Subject unique identifier (X.509 versions 2 and 3 only)

„

Extensions (X.509 version 3 only)

„

Issuer signature

The subject can be an individual, a business, a school, or some other organization, including a Certification Authority (CA). How are certificates created?

Certificates are issued by a Certification Authority (CA), which can be any trusted service or entity willing to vouch for the identities of those to whom it issues certificates, and their association with specific keys. Companies may issue certificates to employees; schools may issue certificates to students, and so forth. The process of requesting and issuing a certificate can be broken down into the following steps: „

Generating a key pair – The applicant generates a public and private key pair or is assigned a key pair by some authority in his organization. If a key is assigned, then some secure method to deliver the keys is required, such as delivery by hand.

„

Requesting the certificate – The applicant collects whatever information the CA requires in order to issue a certificate. The information could include the applicant’s e-mail address, birth certificate, fingerprints, notarized documents — whatever the CA needs in order to be certain that the applicant is who they claim to be. CAs with stringent identification requirements produces certificates with high “assurance.” That is, their certificates generate a high level of confidence. CAs themselves are said to be of high, medium, or low assurance. The applicant sends a certificate request, consisting of his or her public key and the additional required information, to the CA. The certificate request may be encrypted using the CA’s public key. Many requests are made using e-mail, but requests can also be sent by postal or courier service; for example, when the certificate request itself must be notarized.

„

Validating the information – The CA applies whatever policy rules it requires in order to verify that the applicant should receive a certificate. As with identification requirements, a CA’s verification policy and procedures influence the amount of confidence generated by the certificates it issues.

22

Module 7: Exchange Clients and Security

X.509 provides for different classes of certificates. Each class has passed a different degree of verification and thus reflects the level of reliability of the authentication information in the certificate lists. The lowest level is Class 1. For a Class 1 certificate, the identity was verified by the subject providing an e-mail address and the authority sending a reply to this e-mail address. At the other end of the spectrum is Class 4, which requires physical presentation of the subject, and the certificate authority must perform a background check. „

Creating the certificate – The CA creates and signs a digital document containing the applicant’s public key and other appropriate information. The signature of the CA authenticates the binding of the subject’s name to the subject’s public key. The signed document is the certificate.

„

Storing the certificate – The applicant can then store the certificate depending on the software used to request the certificate and the machine configuration this certificate.

„

Publishing the certificate – The CA or the user posts the certificate in a directory as appropriate. The user could also e-mail the certificate to users from whom they wish to receive or send secure messages.

Module 7: Exchange Clients and Security

23

Certificate Authority

Certificates are authenticated, issued, and managed by a trusted third party called a Certification Authority (CA). The CA signs the certificate to make it authentic. Of course, the certificate is only useful if the recipient of the data actually trusts the CA authority. For example, Jack could create a certificate himself by acting as his own CA. But of course, Bob does not trust Jack’s CA and would reject any certificates from him. For a CA to be trusted, it must be well known. In order to trust a CA, you need to store its Certificate in your trusted CA store. Commercial Certificate Authorities

Commercial CAs issue certificates that verify the electronic identity of individuals and organizations on the Web. The primary responsibility of a CA is to confirm the identity of the people and organizations seeking certificates. This effort ensures the validity of the identification information contained in the certificate across organizations. The primary benefit of using a commercial CA is the fact that it is trusted by most people and will allow you to use your certificate outside of your organization.

Certificate Servers

You can implement a certificate server, such as Microsoft® Certificate Server, to manage the issuance, renewal, and revocation of industry-standard certificates. You can use these certificates in conjunction with servers to build a secure Web infrastructure for the Internet or intranet. For large organizations with complex Web needs, certificate servers can offer many advantages over commercial CAs, including lower costs and total control over certificate management policies. However, certificate servers can only be used within the organization since they will not be trusted outside and their certificates would be rejected.

24

Module 7: Exchange Clients and Security

Certificate Hierarchies

Certificate authorities can certify subordinate CAs by signing the certificate of subordinate CAs, which can then issue their own certificates. Therefore, it is possible to create a hierarchy of CAs with clearly defined parent-child relationships. The top-level CA must be trusted without a certificate from any other CA, and its public key must be independently known. The top level CAs can still distribute public keys in certificates but these are self-signed. The other CAs in the hierarchy are certified by parent CA-issued certificates, which bind a CA’s public key to its identity. This hierarchical capability has important implications for non-affiliated entities. Certificates are used to generate confidence in the legitimacy of specific public keys. A certificate must be signed with the issuer’s private key; otherwise, it is not a certificate. Therefore, the issuer’s signature can be verified using the issuer’s public key. If an entity trusts the issuer, then the entity can also have confidence that the public key, contained in the certificate, belongs to the subject named in the certificate. For example, suppose Alice wants to validate Bob’s certificate. She obtains his certificate either by downloading it from the CA’s directory, through e-mail, group policy or preloaded on the system. Her software then looks for the certificate of the CA (root CA certificate), which may be on her local machine or may require a download from the CA. Once in possession of this CA certificate, her software can then use the public key contained in it to decrypt the certificate digest of Bob’s certificate. If the digests match, the final step is to check that the certificate has not expired. Applications and services may use certificates when communicating with other applications and services. Software designed to use certificates maintains a list of trusted certificate authorities. It has become common practice to distribute the public keys of selected CAs with software such as Web browsers and operating systems, and users can add additional public keys as needed. For example, Microsoft® Internet Explorer and Microsoft® Internet Information Services ship with the same list of certificate authorities.

Module 7: Exchange Clients and Security

25

Certificate Revocation List (CRL)

A certificate revocation list (CRL) is a list of certificates that have been revoked before their scheduled expiration date. CRLs only list current certificates (i.e. ones that have not expired). A revoked certificate is removed from the CRL at the end of its validity period. There are a number of reasons why a certificate may become untrustworthy before its expiration date, including: „

Compromise or suspected compromise of an entity’s private key.

„

Fraud in obtaining the certificate.

„

Change in subject status.

„

Issuing CA no longer willing to vouch for subject’s identity.

A certificate is typically revoked because the subject named in the certificate no longer has authority to use the key. If Alice lost her job, for example, her company might place her certificate on its CRL. The determination to revoke a certificate is made by the issuing CA. A CA may revoke any certificate it has issued, at any time, for any reason. For example, an issuing CA may revoke a certificate simply because it no longer wants to vouch for the identity of a certificate’s subject. Microsoft Certificate Services includes the Web address to its CRL in every certificate it creates. It is up to the application that uses the certificate to consult the CRL. The need for revocation information depends on the context in which the certificate is being used. Note If a CA revokes a subordinate CA’s certificate that effectively revokes all the certificates issued by the subordinate.

26

Module 7: Exchange Clients and Security

Lesson 3: Secure Sockets Layer (SSL)

Secure Socket Layer or SSL is a widely used method of securing communication between clients and servers on the TCP/IP networks (e.g. the Internet). This section will describe the SSL protocol, how it works and how to set it up on the different Exchange server protocols including HTTP (Outlook Web Access, for example).

Module 7: Exchange Clients and Security

27

SSL Overview

The SSL protocol was originally developed by Netscape to provide secure communications between a client application such as a Web browser and its corresponding server (Web server). The official standard for this technology is known as Transport Level Security (TLS). SSL is used by most protocols including HTTP, POP3, IMAP, NTTP and LDAP, whereas TLS is used by SMTP. Both SSL and TLS protocols are practically identical in their operation, and therefore, this discussion will refer to this technology as SSL but will apply to TLS as well. SSL is application independent and operates at the transport layer just above the TCP/IP stack. In other words, it does not care which application is using it and operates between the application and TCP/IP on both the server and the client. The TCP/IP sub system must support SSL for it to work; most platforms do. SSL provides two main functions when a client (e.g. Web browser) initiates communication (e.g. requests a page) to a server (e.g. Web server); Authentication and Secure Communication. Authentication

The client can verify that the server is really who it claims to be and not an impersonation (similar to a Trojan). For example, a hacker could set up a Web site which looks identical to a banks on-line service and clients will submit their account passwords believing that it is the bank’s Web site. SSL will allow the client to confirm that the Web site it is talking to is really who it claims to be. This is known as Server Authentication and is mandatory. Server authentication requires the server to have a valid certificate. Optionally, the client can also be authenticated. This is required if the server needs to identify the client. In the bank example, the Web site needs to ensure that the user is really who he says he is before allowing him access to his account. This is not so widely used on the Internet because it requires the client to have a certificate. Therefore, most services such as online banks simply use

28

Module 7: Exchange Clients and Security

passwords to authenticate users. SSL is used, however, to transmit that password securely (encrypted). Secure Communication

The other function of SSL is to encrypt all communications between a client and a server in such a way that only those two processes can decipher what is being sent between them. This will protect the communication from eavesdropping using packet sniffers. Below is a table which shows how passwords are transmitted across the network without SSL. Protocol

Basic Authentication

Integrated Authentication

HTTP

Base64 encoding

Hashed (secure)

SMTP

Base64 encoding

Hashed (secure)

POP3

Plain text

Hashed (secure)

IMAP4

Plain text

Hashed (secure)

Base64 is simply an encoding (data format) it does not actually encrypt. So although the password is not readable, it simply needs decoding using a Base64 decoder, which is widely available. It can even be done using pen and paper using a Base64 table; there are no keys involved. Base64 is analogous to ASCII encoding; i.e. it is NOT secure. Integrated Authentication (NTLM and Kerberos) is a secure method of authentication since it does not involve actually sending the password, but instead sends random data signed (hashed and encrypted) with the password. Although this is the preferred method of authentication on intranets it is specific to Microsoft products and is not generally supported on the Internet. Using SSL on any of these protocols will encrypt every packet of communication between client and server and therefore protect the password even if it sent in plain text. RSA Public Key Cryptography

SSL uses the RSA public/private key protocol to authenticate and negotiate a secure channel. Once the channel has been set up then SSL will encrypt all data using either 40 bits (and recently 56 bits) or 128 bits, depending on the client and server software (most implementations today use 128 bit since 40-bit encryption is no longer considered very secure).

Module 7: Exchange Clients and Security

29

How SSL Works

An SSL connection is always initiated by the client (requesting) process. Below is an outline of the negotiating process used to set up a SSL session: 1. Client connects to server and requests an SSL connection (this is configured on the client as an option or in the URL, e.g. HTTPS). 2. The Server sends its certificate to the client. Remember the certificate contains the identity of the server plus the server’s Public key as well. 3. The client verifies the certificate by checking the issuer’s signature. If there is a problem with the certificate (e.g. client does not trust the issuer’s certification path), then the certificate is rejected or the user may be asked whether to continue or not. 4. If the certificate is okay, then the client generates a random key (40 or 128 bits) and encrypts it with the server’s public key. 5. This encrypted session key is sent to the server. 6. The server receives this encrypted key and uses its own private key to decrypt it. 7. Now both client and server have a shared key which only they know of. 8. All communications (client requests and server responses) are encrypted with this shared key. This is a secure channel. 9. At the end of the communication the session key is discarded. A new one will be created for each SSL session. Note The actual process of authentication and negotiating a shared key has been simplified in the above outline, but is still an accurate description of the overall process. For a more comprehensive explanation, visit Netscape’s Web site.

30

Module 7: Exchange Clients and Security

Setting Up SSL for Exchange Protocols

SSL only requires a certificate on the Server side. The client (e.g. a browser or a POP3 client) simply specifies to use SSL by ticking a check box or specifying it in a URL request. No other configuration is required on the client. SSL will then encrypt the whole communication between Client and Server, thereby rendering any captured data unreadable. Enabling TLS

To enable SSL, you must install a certificate (which supports SSL) on the protocol Virtual Server (VS) that clients will connect to. To do this, go to the properties of the VS and under the Access tab click the Certificate button. The Certificate Wizard will appear. Complete the wizard to install the certificate. Once the wizard is installed, then SSL is available on that VS.

Certificate Wizard

This wizard is implemented by IIS and is used to install certificates on all Virtual Servers. The wizard gives two options for creating a new certificate: „

Prepare the request now but send it later.

„

Send the request immediately to an online certification authority.

The second option is only available if you are using an Active Directory integrated CA (i.e. Microsoft’s Certificate Server installed as an Enterprise CA). This option will send the request, receive the response and install the certificate in one step. Otherwise you must prepare the request which generates the request file which you can manually send to a CA. The CA will return a certificate. You must then restart the wizard and complete the process by importing the certificate.

Module 7: Exchange Clients and Security

31

Note You can also share a certificate between different virtual servers by selecting Assign an Existing Certificate in the wizard. This can be useful if you want to maintain a single consistent identity across all protocols, and also because certificates can be expensive to obtain.

Port Numbers

SSL usually uses a different protocol to the standard one. Below is a list of protocols with the standard and SSL port numbers:

Protocol

Standard Port

SSL Port

SMTP

25

25

HTTP

80

443

POP3

110

995

IMAP4

143

993

NNTP

119

563

LDAP

389

636

32

Module 7: Exchange Clients and Security

Lesson 4: Signing and Sealing E-mail (S/MIME)

This section discusses sealing (encrypting) and signing e-mail messages. This is different from SSL, which encrypts communication between client and server. This difference is explained. This section will discuss the S/MIME protocol for signing and sealing. S/MIME is used widely on the Internet. Topics covered include how S/MIME works, how to set it up, including acquiring a certificate and how to use S/MIME.

Module 7: Exchange Clients and Security

33

S/MIME Overview

SSL (and also MAPI encryption) encrypt communication over the wire between two points (e.g. mail client to mail server). This has a couple of limitations:

S/MIME

„

Only the route between client and server is encrypted. If the message is taking several hops to reach its destination then not all points may be secure.

„

Message is not stored in encrypted format. Therefore, it is at risk from anyone who has access to the message store. For example, administrators in Exchange have the ability to access any mailbox.

„

SSL provides no method to sign messages for user verification. In other words, you can still use an SSL connection to send a message while pretending to be someone else.

S/MIME provides end-to-end message security through two main functions: „

Sealing – This is message encryption and protects messages from unauthorized access on the network or in storage.

„

Signing – Digitally signs the message so that the sender and the data can be verified. This means two things; first the recipient can verify that the sender really is who they say they are (this prevents spoofing or forging e-mail addresses; a common Telnet trick), and also verifies that the data has not changed since it was signed (this prevents tampering with the message).

End-to-end means that the actual signing and sealing (as well as the decryption and signature verification) is done on the clients. In other words, the sender of the message encrypts and/or signs the message and then he submits it for delivery. The message is delivered to the recipient’s mailbox in its encrypted state. The server does not care about the message content; it simply delivers a blob of data. When the recipient reads the message, he downloads it from his mailbox to his client and there it is decrypted and/or verified.

34

Module 7: Exchange Clients and Security

The server is not involved in any part of this process. In fact, no certificates or configuration is required on the server side. S/MIME Drawbacks

S/MIME Standard

S/MIME provides complete security for e-mail messages; much more than SSL/TLS offers. However, S/MIME has the following drawbacks: „

Clients must support S/MIME – Most email clients support S/MIME at the moment. However, because S/MIME requires processing on the client side Web-based e-mail (e.g. Outlook Web Access) cannot support S/MIME.

„

Clients need certificates – Each client participating in S/MIME requires a certificate in order to send and receive signed and sealed messages. This can be expensive if using a commercial CA. If using an internal CA such as Microsoft Certificate Server, then communication is limited to within the organization. Certificates also need to be managed, and users may not be fully aware of how to do this, e.g. certificate storage, expiry and renewal, revocation lists, etc.

„

Clients need to be configured – As well as acquiring a certificate, the user must also configure his e-mail client to use the certificate to sign and seal emails. This requires more than just selecting a check box as with SSL. There are many options to consider and for non technical users this may be difficult.

„

Clients need to swap certificates – To complicate things further, clients can only encrypt with each other if they swap public keys (by swapping certificates). This is not so easily done, and the user must go through precise steps to achieve this (covered later in this section). Again, non-technical users would have difficulty. S/MIME is not just a click and go protocol. Certain things, such as storing certificates in a directory (e.g. Active Directory), will simplify this process. However, this is limited to within the organization.

S/MIME was originally developed by RSA but has become an open standard. It is defined by the following RFCs: „

Version 2 Defined in RFCs 2311 and 2312

„

Version 3 Defined in RFCs 2362 and 2363

Most e-mail clients today support S/MIME; this includes Microsoft® Outlook® 98 and later, Microsoft® Outlook Express and most third-party clients such as Eudora.

Module 7: Exchange Clients and Security

35

How S/MIME Works

Sealing (Encrypting) Messages

Signing Messages

To send someone an encrypted message, you must have their public key to perform the encryption with. In other words, you need their certificate (which contains their public key). Because asymmetric (public) key encryption is inefficient and slow, and also the possibility of the user sending to multiple recipients, the lock box method is used: „

Client creates a random key and encrypts the message with this key using a symmetric algorithm. S/MIME specification recommends (but is not limited to) DES (56-bit), Triple DES (168-bit) and RC2 (128-bit). This means that the message can only be decrypted using this random key.

„

Create a copy of the random key, encrypt it with the recipient’s public key (derived from their certificate) and attach the result to the message. This is performed for each recipient of this message.

„

The message and its key attachments are sent together to the recipients.

„

Upon receiving the message, the recipient locates their corresponding key attachment, uses their private key to decrypt the symmetric key and then uses that symmetric key to decrypt the message.

Signing is used to verify the sender (anti-spoofing) and the data (antitampering). The message is signed and verified as follows: „

The sender creates a hash of the message and encrypts it with their private key. This ensures that no one else can reproduce this signature.

„

The encrypted hash is sent with the message. The sender’s certificate is usually sent with signed messages as well.

„

Upon receiving the message, the recipient uses the sender’s public key to verify hash.

The last point needs further explanation. On receipt of the message, the certificate (included with the message) is checked to see that the public key it

36

Module 7: Exchange Clients and Security

contains is associated with the user claimed in the message (remember certificates are issued by trusted authorities). The public key is used to decrypt the hash. If the hash was not encrypted by this public key’s corresponding private key then this would fail and it would mean that the owner of this certificate did NOT sign the message. Otherwise, the decrypted hash is compared with a hash of the message generated locally by the recipient. If they match, then it means that the message is exactly the same as it was at the time of signing and has not been tampered with. Important S/MIME encrypts the message and creates a special S/MIME attachment which is sent through an e-mail system. Other parts of the message such as the header are transmitted as normal, for example in SMTP this would be in plain text. Therefore, header fields such as Subject are not encrypted. If a non-S/MIME client receives an S/MIME message they would simply see an attachment which contained garbled text. They would also not be able to verify the signature.

Module 7: Exchange Clients and Security

37

Setting Up S/MIME

As stated earlier, S/MIME is a client application. Therefore, its setup is specific to the client being used. However, in all cases the basic steps are the same: install a certificate and configure the client to use that certificate. The slide shows the S/MIME configuration of Outlook. Before you can configure S/MIME, you must obtain a certificate from a CA. Outlook will check to see if you have an appropriate certificate installed when you try to enable S/MIME. If no certificate is detected then Outlook gives you the option of obtaining a certificate from a commercial CA or from Key Management Server (KMS). If getting a certificate from KMS, then the administrator must generate a Security Token and securely pass it to the user. If a certificate is obtained directly from a CA then no Administrator intervention is required. Note Administrators cannot prevent users from acquiring certificates and setting up S/MIME on their mailboxes.

38

Module 7: Exchange Clients and Security

Getting a Certificate

S/MIME requires the user to obtain a certificate. There are three places to obtain certificates for use with email clients: „

Internal CA – This has the benefit of being free to users. It can also be controlled by the organisation and can integrate with Active Directory to publish certificates. However, unless your CA is a subordinate of a commercial CA then these certificates can only be used internally within the organization. This is a sever limitation.

„

Commercial CA – The benefit of using a commercial CA is that your certificate can be used anywhere on the Internet. However, you generally have to pay to obtain this certificate, and depending on the security level required the cost can be high. Also, the CA will ask for information to validate your identity.

„

Key Management Server (Exchange 2000 only) – KMS will actually use a Microsoft CA to acquire a certificate on behalf of the user and therefore, the same arguments apply as using an Internal CA. The benefits to the user is that the whole process is simplified since the user simply needs to enter a Security Token (string of letters) issued by the administrator to that user. However KMS is only supported on Outlook clients.

Module 7: Exchange Clients and Security

39

Swapping Public Keys

Signing a message simply requires the sender to have a certificate (which means they have a valid public/private key pair). However, in order to encrypt messages then you must have the certificate (includes the public key) of the recipients you intend to send sealed messages to. If you are using an internal Enterprise CA (this includes KMS) then all issued user certificates are stored in Active Directory and clients can access them directly. However, for external (outside of the organization) communication, or if a commercial CA has been used for the certificates, then users need to manually swap certificates. Suppose Alice wants to send Bob an encrypted message. Bob must first send his certificate to Alice. This can be done in several ways: „

Export the certificate and manually send it to Alice as an attachment. Alice would then create an entry for Bob in her address book (e.g. Contacts) and import Bob’s certificate into this entry. Alice would then use this entry to send encrypted messages to Bob.

„

An easier method is to include your certificate with your signed messages. This is an option you can set on your client as shown in the slide. Bob would then simply send a signed message to Alice. When Alice receives the message she would extract the certificate and store it in Bob’s entry in her address book. The way this is done depends on the client. In Outlook, for example, Alice would open the message and right-click on Bob’s name in the From field, she would then select Add to Contacts from the pop-menu. This will create an entry for Bob in her Contacts folder and would automatically add Bob’s certificate to that entry.

The above procedure would need to be performed in reverse if Bob wants to send Alice encrypted information. Indeed, certificates need to be swapped whenever two users need to send sealed messages between themselves.

40

Module 7: Exchange Clients and Security

Review

1. List three methods of allowing Outlook clients to connect to Exchange across the Internet through a firewall.

2. What is the difference between symmetric and asymmetric encryption?

3. How is a digital signature on a message created?

4. What is a Certificate Revocation List or CRL?

5. What is required to setup SSL on an Exchange Virtual Server (e.g. SMTP, HTTP, POP3, etc)?

6. What is the replacement for the Key Management Server in Exchange 2003?