W07 Exchange Clients Security

8/14/2019 W07 Exchange Clients Security

1/42

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

Module 7: ExchangeClients and Security


2/42

Information in this document, including URL and other Internet Web site references, is subject tochange without notice. Unless otherwise noted, the example companies, organizations, products,domain names, e-mail addresses, logos, people, places and events depictedherein 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 applicablecopyright laws is the responsibility of the user. Without limiting the rights under copyright, no partof this document may be reproduced, stored in or introduced into a retrieval system, or transmittedin 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 intellectualproperty rights covering subject matter in this document. Except as expressly provided in anywritten license agreement from Microsoft, the furnishing of this document does not give you anylicense 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 inthe United States, and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their

respective owners.


3/42

Module 7: Exchange Clients and Security 1

Overview

This module will look at the different ways that users can remotely access theirMicrosoft

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 willbe discussed.


4/42

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.


5/42


Outlook and ISA RPC Filter

Microsoft

Internet Security and Acceleration (ISA) Server's Remote ProcedureCall Protocol(RPC) application filter enables secure communication betweenMicrosoft

Outlook

clients and an Exchange Server over the Internet. The

RPC application filter protects RPC communication over the Internet byidentifying which specific RPC interface is requested and allowing only calls tothose interfaces. Furthermore, the RPC application filter opens portsdynamically, meaning that the communication is allowed only when it isspecifically requested.

In addition, Exchange Server communicates with Outlook clients using alightweight User Datagram Protocol (UDP)-based protocol. The RPCapplication filter also processes new mail notification as follows: when anOutlook client logs on to an Exchange Server, it registers to receive new mailnotifications 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 theport. To allow this type of notification, standard firewalls must typically open awide range of ports. With the RPC application filter enabled, ISA Serverintercepts registration for new mail and dynamically opens only the necessaryports.

Thus, Exchange Server publishing is more secure with the ISA Server firewall.

The RPC Filter is part of ISA Feature Pack 1.

In an Exchange Server/Outlook client scenario, the RPC application filterworks as follows:

1. The Outlook client issues request over Port 135 (TCP) through ISA Serverto the Exchange Server, to find the service port number associated with theExchange RPC universal unique identifier (UUID).

Note

How the RPCApplication Filter Works


6/42


2. The Exchange Server sends a response back through the ISA Server to theOutlook 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 andmaintains it in a table.

4. ISA Server allocates a new port on the ISA Server itself and changes theresponse that it sends to the Outlook client to reflect this change. Thisinformation is also maintained in the table.

5. The Outlook client issues a request seemingly to the Exchange Server, butactually to the new port on the ISA Server. The ISA Server then sends thepacket to the Exchange Server. Only communication over this port isallowed.

When the Outlook client connects to an Exchange Server, the Exchange Serverinstructs the Outlook client to communicate directly with an Active Directory

Global Catalog for address book look ups. In the publishing scenarios describedin this paper, this direct communication will not function properly if theOutlook client is on the Internet, while the Global Catalog is on the corporate

Intranet. This is because ISA Server does not publish any Global Catalogserver.

Microsoft

Exchange 2000 Server and Exchange 2003, however, have theability to act as a directory service proxy for older clients, which cannot connectto 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 ispossible to disable the Referral service so that all Outlook clients will useDSProxy. This means that Outlook clients will no longer attempt to connect toglobal catalogs directly, but will submit all their address book look ups via theExchange server. To achieve this, implement the following registry change onthe Exchange server:

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

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 theRPC encryption available on the operating system to encrypt all RPCcommunication between Outlook and Exchange (usually 128 bit).

ISA Feature Pack 1 as the ability to reject any Outlook traffic which does nothave encryption enabled. This is achieved by the following registry change onthe ISA server:

HKLM\Software\Microsoft\RPC\PluginRPC

Value: MinimumAuthenticationLevel (DWORD)

Data: 2 (force RPC encryption)

Forcing DSProxy

Forcing RPC Encryption


7/42


Outlook 2003 RPC Over HTTPS

Outlook 2003 has the ability to make an RPC connection to an Exchange serverusing a HTTPS (Secure Sockets Layer [SSL]) tunnel. In effect, all the RPCtraffic is encapsulated into HTTPS traffic and sent to you Exchange server viaan RPC Proxy server. (See the Outlook 2003 module for more details.)

This feature gives users the ability to have the full blown features of Outlookwith the network flexibility of Outlook Web Access. For many users, thisfeature has meant that the no loner use Outlook Web Access for accessing theire-mail over the Internet.

Because HTTPS is used, then all the RPC communication is protected by 128-bit encryption, and is therefore secure.


8/42


Outlook Web Access

Outlook Web Access has been the main method for users gaining access to theirExchange mailbox over the Internet. Outlook Web Access has beencontinuously 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 moreadvanced collaboration software.

Outlook Web Access can use (and enforce) HTTPS access, and is thereforecompletely secure.


9/42


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 theircommunication.


10/42


11/42


Overview of Cryptography

The security objectives of most applications and communications are simple:

Hiding Data You want to ensure that data transmitted (or stored) cannotbe seen (i.e. is illegible) by unwanted parties.

Authentication/Identifying Originator You may need to be able toidentify an entity. For example, someone requesting access to a bankaccount needs to be identified as the account holder. Used extensively onnetworked resources such as file shares and -email accounts. As well asidentifying an entity such as a user, you may also need to identify the authorof a piece of data. For example, if an accounts department receives an emailfrom 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 wantto 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 customeraccount to the phone company to pay a bill. As well as the companyidentifying that the sender is the account holder, it needs to verify that thesum requested is the claimed $10,000 on the request!

Non-Repudiation Sometimes it is necessary to prove that a person sent orauthored 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 crasheddown, the client may deny having sent the purchase request. A way isneeded to prove that the client actually sent the message. In many cases,contracts made and signed using cryptographic technologies are now seen astotally 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: anEncryption algorithm (known as Ciphers,of which there are two fundamentaltypes) and a hashing algorithm.


12/42


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


13/42


Symmetric (Secret Key) Encryption

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

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

original data and must be computationally infeasible to transform back to theoriginal data without the original key.

Symmetric-key cryptography is a straightforward process for a single userencrypting and decrypting files on a standalone computer (e.g. the passwordprotect feature in Microsoft Word uses symmetric encryption).

However, a number of issues arise when two users want to send encryptedmessages to each other. They must agree on a shared secret key, and each musttrust the other not to divulge the key. When the key is transmitted from one userto another, it must be transmitted in such a way that an adversary cannotintercept 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. Alicecannot send the key to Bob because a third party may intercept it and use it todecrypt Alices messages to Bob.

Symmetric Key Cryptographys main advantage is that the algorithms arecomputationally relatively simple and therefore, fast to process. Severalalgorithms have been published with varying key lengths, performance, andsecurity. These include:

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

How Symmetric CiphersWork

Key Distribution

Symmetric Ciphers


14/42


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

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

RC2, 3 and 5 These ciphers were developed by Ron Rivest of RSA DataSecurity Inc. RC stands for Rivets Ciphers. RC5 is the latest version of thiscipher series. Although RC5 has a variable key size (0 to 2048 bits), it istypically 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 isto break. A 40-bit key has 2

40(1099511627776) permutations. However, the

longer the key length, the more processing is required to encrypt (and decrypt) apiece of data.

A 56-bit key has 65,536 times more permutations than a 40-bit key. In otherwords if a brute force hacking algorithm takes one hour to crack a 40-bit key, itwill 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 morecombinations than a 40-bit key. So as you can see, 128 bits is MUCH moresecure.

Key Lengths


15/42


Asymmetric (Public/Private Key) Encryption

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

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

Because the two keys are therefore related (generated togethermathematically), it must be computationally infeasible to generate one keyby having the other.

So to summarize, one key is used to encrypt a piece of data while the otherdecrypts 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.

The main feature of these algorithms is the simplicity of key distribution. Eachuser 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 toit).

This way you can securely send a piece of data to a user by encrypting it withtheir public key. Only that user can decrypt it because it requires their privatekey.

For example, Alice wants to send Bob a secure message. Bob sends Alice hisPublic key which Alice uses to encrypt the message with. It does not matter thata third party has access to the Public key since it cannot be used to decrypt themessage. The encrypted message is sent to Bob who uses his Private key todecrypt the data.

Public keys can be held in a public location, for example in a directory orGlobal Address List (GAL) so that users can send data to each other easily. Theprivate key must be protected at all costs, because if it is compromised then allencrypted data sent to you can be decrypted with it.

Key Distribution andPublic and Private Keys


16/42


The main disadvantage of Asymmetric ciphers is that the algorithms involvedare computationally complex and therefore should not be used to encrypt largevolumes of data. In order to make it very difficult to compute the private keyfrom 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. TheDiffie-Hellman key agreement protocol allows two entities to establish asecret key without having any prearranged shared secrets between them.The Diffie-Hellman protocol uses public key technology to generate asession key. It is based on using very large prime numbers.

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

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

Asymmetric Ciphers


17/42


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 andrequire much processing. For example if Alice wants to send Bob a 1 MBfinancial spreadsheet, a Public key encryption would take a long time toperform, 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 somedata (e.g. a mail message) to multiple recipients securely. If you use Public keyencryption, then whose public key will you use to encrypt the message? In

actuality, you must send a separate copy of the message to each recipientencrypted with that recipients public key. This is inefficient in terms ofnetwork traffic and storage.

A solution using a combination of Asymmetric and Symmetric key encryptionsolves both the above problems. It works as follows (assume all users havepublic/private key pair):

Alice wants to send Bob a large piece of data. Alice generates a random keyand encrypts the message with it using symmetric encryption which is fast andefficient. She then uses Bobs public key to encrypt the symmetric key andattach 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 heuses to decrypt the message itself.

In effect Alice is taking the key to the message and locking it with therecipients public key, this is called a lock box.

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 theabove example except that two copies of the symmetric key are attached, eachone encrypted with that recipients public key. The overhead of the extra keys ismuch less then if you had to send the message out multiple times.

Lock Box Solution

Multiple Recipients


18/42


Hashing Algorithms

Hashing algorithms produce a hash (or digest) of a given piece of data. A hashworks on a similar principle to CRC (Cyclic Redundancy Check) or parity butis much more sophisticated. You can think of a hash as a unique fingerprint ofa given piece of data. A good hashing algorithm should support the followingproperties for its hashes:

Small and Fixed Size Regardless of the size of the data, the hash shouldbe relatively small and be of fixed size. So two messages, one being 10 MBand 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 differenthashes. It should be almost impossible for two different pieces of data toproduce the same hash value.

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

Irreversible Statistically, it should be infeasible to reverse the hashingprocess 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 canverify that the data received is the same data that was sent. For example Alicewants to send Bob a message, and she must ensure that Bob receives themessage unmodified (for example, by a noisy network connection). Sheproduces a hash of the message and sends it together with the message. WhenBob receives the message, he uses the same algorithm to generate a hash ofwhat he has received. Bob then compares the hash that he generated with thehash that Alice sent him. If the data has not been modified in transit, the twohashes should be identical.


19/42


Hashing algorithms in use today include:

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

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

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

Hashing (Digest)Algorithms

Note


20/42


Digital Signatures

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

Verifies the Sender Just like a normal signature, a digital signatureverifies the sender or author of the data, because only that person cangenerate this signature.

Verifies the authenticity of the data That is, the data has not beenmodified since it was signed.

There are two steps involved in creating a digital signature from a message. Thefirst step is to create a hash value from the message. The hash value is oftenreferred to as a message digest.

The second step is to encrypt the message digest with the senders private key.This encryption step is referred to as signing, and the encryption algorithm issometimes referred to as a signature algorithm. The message digest is encryptednot for confidentiality, but to provide a means for verifying the integrity andauthenticity of the message.

The private key is used to encrypt the hash because only the signatory hasaccess 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 theirhash values. Therefore, it is typical to compute the digital signature to adocument on the documents hash value rather than on the document itself.

Signing a message does not alter the message; it simply generates a digitalsignature string that can either be bundled with the message or transmittedseparately.

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

Creating a DigitalSignature

Digital SignatureExample


21/42


encrypts the message digest with her private signature key to create the digitalsignature, which she sends to Bob along with the message

When he receives the message and signature, Bob decrypts the signature withAlices public signature key to recover the message digest. He then hashes themessage, using the same hash function that Alice used, and compares the resultto the message digest that he recovered from Alices signature. If they are

equal, he can be confident that the message came from Alice (or from someonein possession of Alices private key), and that the contents of the message werenot altered after the message was signed.


22/42


Certificates

There is one big problem so far when using asymmetric encryption and digitalsignatures. You assume that a public key that you are using really belongs towho you think it does.

For example, say that our bad guy Jack wants to send a message to Bob andmake it appear that it is from Alice. He composes the message and creates ahash of it. Jack does not have access to Alices private key to sign the hashwith. Instead Jack encrypts it with his own private key and gives the message toBob 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 Bobs only defense is a mechanism to tie a public key with a user.This is what certificates are used for.

A certificate (digital certificate, public-key certificate) is a digital document thatattests to the binding of a public key to an entity. The main purpose of acertificate is to generate confidence that the public key contained in thecertificate actually belongs to the entity named in the certificate.

A certificate contains a public key as well as information including the name ofthe owner of the public key, their e-mail address, and other information. Thisinformation is verified as correct by the issuer of the certificate placing a DigitalSignature on the certificate. Issuers of certificates are called Certificate

Authorities and are discussed on the next slide.

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

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

Certificates

Certificate Types

X.509 Certificates


23/42


24/42


X.509 provides for different classes of certificates. Each class has passed adifferent degree of verification and thus reflects the level of reliability of theauthentication 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 sendinga 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 certificateauthority must perform a background check.

Creating the certificate The CA creates and signs a digital documentcontaining the applicants public key and other appropriate information. Thesignature of the CA authenticates the binding of the subjects name to thesubjects public key. The signed document is the certificate.

Storing the certificate The applicant can then store the certificatedepending on the software used to request the certificate and the machineconfiguration 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 usersfrom whom they wish to receive or send secure messages.


25/42


Certificate Authority

Certificates are authenticated, issued, and managed by a trusted third partycalled a Certification Authority (CA). The CA signs the certificate to make itauthentic. Of course, the certificate is only useful if the recipient of the dataactually 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 Jacks CA and would reject any certificatesfrom 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 CAs issue certificates that verify the electronic identity ofindividuals and organizations on the Web. The primary responsibility of a CAis to confirm the identity of the people and organizations seeking certificates.This effort ensures the validity of the identification information contained in thecertificate across organizations. The primary benefit of using a commercial CAis the fact that it is trusted by most people and will allow you to use yourcertificate outside of your organization.

You can implement a certificate server, such as Microsoft Certificate Server,to manage the issuance, renewal, and revocation of industry-standardcertificates. You can use these certificates in conjunction with servers to build asecure Web infrastructure for the Internet or intranet. For large organizations

with complex Web needs, certificate servers can offer many advantages overcommercial CAs, including lower costs and total control over certificatemanagement policies.

However, certificate servers can only be used within the organization since theywill not be trusted outside and their certificates would be rejected.

Commercial CertificateAuthorities

Certificate Servers


26/42


Certificate Hierarchies

Certificate authorities can certify subordinate CAs by signing the certificate ofsubordinate CAs, which can then issue their own certificates. Therefore, it ispossible to create a hierarchy of CAs with clearly defined parent-childrelationships. The top-level CA must be trusted without a certificate from anyother CA, and its public key must be independently known. The top level CAscan still distribute public keys in certificates but these are self-signed. The otherCAs in the hierarchy are certified by parent CA-issued certificates, which bind aCAs public key to its identity. This hierarchical capability has importantimplications for non-affiliated entities.

Certificates are used to generate confidence in the legitimacy of specific publickeys. A certificate must be signed with the issuers private key; otherwise, it isnot a certificate. Therefore, the issuers signature can be verified using theissuers public key. If an entity trusts the issuer, then the entity can also haveconfidence that the public key, contained in the certificate, belongs to thesubject named in the certificate.

For example, suppose Alice wants to validate Bobs certificate. She obtains hiscertificate either by downloading it from the CAs directory, through e-mail,group policy or preloaded on the system. Her software then looks for thecertificate of the CA (root CA certificate), which may be on her local machineor 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 decryptthe certificate digest of Bobs certificate. If the digests match, the final step is tocheck that the certificate has not expired.

Applications and services may use certificates when communicating with otherapplications and services. Software designed to use certificates maintains a listof trusted certificate authorities. It has become common practice to distributethe public keys of selected CAs with software such as Web browsers andoperating systems, and users can add additional public keys as needed. Forexample, Microsoft

Internet Explorer and Microsoft

Internet Information

Services ship with the same list of certificate authorities.


27/42


Certificate Revocation List (CRL)

A certificate revocation list (CRL) is a list of certificates that have been revokedbefore their scheduled expiration date. CRLs only list current certificates (i.e.ones that have not expired). A revoked certificate is removed from the CRL atthe end of its validity period.

There are a number of reasons why a certificate may become untrustworthybefore its expiration date, including:

Compromise or suspected compromise of an entitys private key.

Fraud in obtaining the certificate.

Change in subject status.

Issuing CA no longer willing to vouch for subjects identity.

A certificate is typically revoked because the subject named in the certificate nolonger has authority to use the key. If Alice lost her job, for example, hercompany might place her certificate on its CRL.

The determination to revoke a certificate is made by the issuing CA. A CA mayrevoke any certificate it has issued, at any time, for any reason. For example, anissuing CA may revoke a certificate simply because it no longer wants to vouch

for the identity of a certificates subject.

Microsoft Certificate Services includes the Web address to its CRL in everycertificate it creates. It is up to the application that uses the certificate to consultthe CRL. The need for revocation information depends on the context in whichthe certificate is being used.

If a CA revokes a subordinate CAs certificate that effectively revokes allthe certificates issued by the subordinate.Note


28/42


Lesson 3: Secure Sockets Layer (SSL)

Secure Socket Layer or SSL is a widely used method of securingcommunication between clients and servers on the TCP/IP networks (e.g. theInternet).

This section will describe the SSL protocol, how it works and how to set it upon the different Exchange server protocols including HTTP (Outlook WebAccess, for example).


29/42


SSL Overview

The SSL protocol was originally developed by Netscape to provide securecommunications between a client application such as a Web browser and itscorresponding server (Web server). The official standard for this technology isknown as Transport Level Security (TLS). SSL is used by most protocolsincluding HTTP, POP3, IMAP, NTTP and LDAP, whereas TLS is used bySMTP.

Both SSL and TLS protocols are practically identical in their operation, andtherefore, 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 theTCP/IP stack. In other words, it does not care which application is using it andoperates 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) initiatescommunication (e.g. requests a page) to a server (e.g. Web server);Authentication and Secure Communication.

The client can verify that the server is really who it claims to be and not animpersonation (similar to a Trojan). For example, a hacker could set up a Website which looks identical to a banks on-line service and clients will submit their

account passwords believing that it is the banks Web site. SSL will allow theclient 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 authenticationrequires the server to have a valid certificate.

Optionally, the client can also be authenticated. This is required if the serverneeds to identify the client. In the bank example, the Web site needs to ensurethat the user is really who he says he is before allowing him access to hisaccount. This is not so widely used on the Internet because it requires the clientto have a certificate. Therefore, most services such as online banks simply use

Authentication


30/42


passwords to authenticate users. SSL is used, however, to transmit thatpassword securely (encrypted).

The other function of SSL is to encrypt all communications between a clientand a server in such a way that only those two processes can decipher what isbeing sent between them. This will protect the communication fromeavesdropping 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. Soalthough the password is not readable, it simply needs decoding using a Base64decoder, which is widely available. It can even be done using pen and paperusing a Base64 table; there are no keys involved. Base64 is analogous to ASCIIencoding; i.e. it is NOT secure.

Integrated Authentication (NTLM and Kerberos) is a secure method ofauthentication since it does not involve actually sending the password, butinstead sends random data signed (hashed and encrypted) with the password.Although this is the preferred method of authentication on intranets it is specificto Microsoft products and is not generally supported on the Internet.

Using SSL on any of these protocols will encrypt every packet ofcommunication between client and server and therefore protect the passwordeven if it sent in plain text.

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

Secure Communication

RSA Public KeyCryptography


31/42


How SSL Works

An SSL connection is always initiated by the client (requesting) process. Belowis 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 configuredon the client as an option or in the URL, e.g. HTTPS).

2. The Server sends its certificate to the client. Remember the certificatecontains the identity of the server plus the servers Public key as well.

3. The client verifies the certificate by checking the issuers signature. If there

is a problem with the certificate (e.g. client does not trust the issuerscertification path), then the certificate is rejected or the user may be askedwhether to continue or not.

4. If the certificate is okay, then the client generates a random key (40 or 128bits) and encrypts it with the servers 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 todecrypt 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 encryptedwith this shared key. This is a secure channel.

9. At the end of the communication the session key is discarded. A new onewill be created for each SSL session.

The actual process of authentication and negotiating a shared key hasbeen simplified in the above outline, but is still an accurate description of

the overall process. For a more comprehensive explanation, visit NetscapesWeb site.

Note


32/42


Setting Up SSL for Exchange Protocols

SSL only requires a certificate on the Server side. The client (e.g. a browser or aPOP3 client) simply specifies to use SSL by ticking a check box or specifying itin a URL request. No other configuration is required on the client. SSL willthen encrypt the whole communication between Client and Server, therebyrendering any captured data unreadable.

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

This wizard is implemented by IIS and is used to install certificates on allVirtual 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 Directoryintegrated CA (i.e. Microsofts Certificate Server installed as an EnterpriseCA). This option will send the request, receive the response and install thecertificate in one step.

Otherwise you must prepare the request which generates the request file whichyou can manually send to a CA. The CA will return a certificate. You must thenrestart the wizard and complete the process by importing the certificate.

Enabling TLS

Certificate Wizard


33/42


You can also share a certificate between different virtual servers byselecting Assign an Existing Certificate in the wizard. This can be useful

if you want to maintain a single consistent identity across all protocols, and alsobecause certificates can be expensive to obtain.

SSL usually uses a different protocol to the standard one. Below is a list ofprotocols 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

Note

Port Numbers


34/42


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

This section discusses sealing (encrypting) and signing e-mail messages. This isdifferent 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/MIMEis 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.


35/42


S/MIME Overview

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

Only the route between client and server is encrypted. If the message istaking 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 fromanyone who has access to the message store. For example, administrators inExchange have the ability to access any mailbox.

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

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

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

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

End-to-end means that the actual signing and sealing (as well as the decryptionand signature verification) is done on the clients. In other words, the sender ofthe message encrypts and/or signs the message and then he submits it fordelivery. The message is delivered to the recipients mailbox in its encryptedstate. The server does not care about the message content; it simply delivers ablob of data. When the recipient reads the message, he downloads it from hismailbox to his client and there it is decrypted and/or verified.

S/MIME


36/42


37/42


How S/MIME Works

To send someone an encrypted message, you must have their public key toperform the encryption with. In other words, you need their certificate (whichcontains their public key). Because asymmetric (public) key encryption isinefficient and slow, and also the possibility of the user sending to multiplerecipients, the lock box method is used:

Client creates a random key and encrypts the message with this key using asymmetric algorithm. S/MIME specification recommends (but is not limitedto) 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 recipients public key(derived from their certificate) and attach the result to the message. This isperformed 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 keyattachment, uses their private key to decrypt the symmetric key and thenuses that symmetric key to decrypt the message.

Signing is used to verify the sender (anti-spoofing) and the data (anti-

tampering). 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 senders certificate isusually sent with signed messages as well.

Upon receiving the message, the recipient uses the senders public key toverify hash.

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

Sealing (Encrypting)Messages

Signing Messages


38/42


contains is associated with the user claimed in the message (remembercertificates are issued by trusted authorities).

The public key is used to decrypt the hash. If the hash was not encrypted by thispublic keys corresponding private key then this would fail and it would meanthat the owner of this certificate did NOT sign the message. Otherwise, thedecrypted 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 itwas at the time of signing and has not been tampered with.

S/MIME encrypts the message and creates a special S/MIMEattachment which is sent through an e-mail system. Other parts of the messagesuch as the header are transmitted as normal, for example in SMTP this wouldbe 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 anattachment which contained garbled text. They would also not be able to verifythe signature.

Important


39/42


Setting Up S/MIME

As stated earlier, S/MIME is a client application. Therefore, its setup is specificto 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 slideshows 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 whenyou try to enable S/MIME. If no certificate is detected then Outlook gives youthe option of obtaining a certificate from a commercial CA or from Key

Management Server (KMS). If getting a certificate from KMS, then theadministrator must generate a Security Token and securely pass it to the user. Ifa certificate is obtained directly from a CA then no Administrator interventionis required.

Administrators cannot prevent users from acquiring certificates andsetting up S/MIME on their mailboxes.Note


40/42


Getting a Certificate

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

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

Commercial CA The benefit of using a commercial CA is that yourcertificate can be used anywhere on the Internet. However, you generallyhave to pay to obtain this certificate, and depending on the security levelrequired the cost can be high. Also, the CA will ask for information tovalidate your identity.

Key Management Server (Exchange 2000 only) KMS will actually usea 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 useris that the whole process is simplified since the user simply needs to enter aSecurity Token (string of letters) issued by the administrator to that user.However KMS is only supported on Outlook clients.


41/42


Swapping Public Keys

Signing a message simply requires the sender to have a certificate (whichmeans they have a valid public/private key pair). However, in order to encryptmessages then you must have the certificate (includes the public key) of therecipients you intend to send sealed messages to.

If you are using an internal Enterprise CA (this includes KMS) then all issueduser certificates are stored in Active Directory and clients can access themdirectly.

However, for external (outside of the organization) communication, or if acommercial CA has been used for the certificates, then users need to manuallyswap certificates.

Suppose Alice wants to send Bob an encrypted message. Bob must first sendhis certificate to Alice. This can be done in several ways:

Export the certificate and manually send it to Alice as an attachment. Alicewould then create an entry for Bob in her address book (e.g. Contacts) andimport Bobs certificate into this entry. Alice would then use this entry tosend 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 themessage she would extract the certificate and store it in Bobs entry in heraddress book. The way this is done depends on the client. In Outlook, forexample, Alice would open the message and right-click on Bobs name inthe 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 wouldautomatically add Bobs certificate to that entry.

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


42/42


Review

1. List three methods of allowing Outlook clients to connect to Exchangeacross 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 Exchange2003?

W07 Exchange Clients Security

Documents

Transcript of W07 Exchange Clients Security