Diffie Hellman key exchange uses asymmetric encryption to exchange session keys

Asymmetric Key Algorithms

Asymmetric key algorithms aren't as widely used as their symmetric counterparts. So we'll just go over two of the big ones: Diffie-Hellman and RSA.

Diffie-Hellman: The Diffie-Hellman algorithm was one of the earliest known asymmetric key implementations. The Diffie-Hellman algorithm is mostly used for key exchange. Although symmetric key algorithms are fast and secure, key exchange is always a problem. You have to figure out a way to get the private key to all systems. The Diffie-Hellman algorithm helps with this. The Diffie-Hellman algorithm will be used to establish a secure communication channel. This channel is used by the systems to exchange a private key. This private key is then used to do symmetric encryption between the two systems.

RSA: It is the Rivest Shamir Adelman algorithm. RSA was developed in 1978. RSA was the first widely used asymmetric algorithms used for signing and encryption. It supports key lengths of 768 and 1,024 bits. The RSA algorithm uses a three-part process. The first part is key generation. The keys used in the RSA algorithm are generated using mathematical operations based on prime numbers. The second part of the process is encryption. This encryption is done using one of the keys in the key pair. The third part of the process is decryption. The decryption is done using the other key in the key pair.

Diffie–Hellman Key Exchange Protocol

Based on public key cryptography, the D-H algorithm is a method for securely exchanging a shared key between two parties over an untrusted network. It is an asymmetric cipher used by several protocols including SSL, SSH, and IPSec. It allows two communicating parties to agree upon a shared secret, which can then be used to secure a communication channel.

The D-H algorithm requires each of the communicating parties to have public/private key pairs. By the sender using a private key and the receiver using a public key, the sender and the receiver compute a shared secret number. If the same public/private key pairs of the same sender and recipient are used, both parties will arrive at the same number.

This number is then used as a shared symmetric cryptographic key and can be used as a key-encryption key (KEK) or to generate a content-encryption key (CEK). The CEK is commonly known as a session key. To prevent the same key from being generated in subsequent communication sessions, a random value is incorporated into the initial KEK generation process. This ensures that the resulting KEK is unique for each communication session.

In IPSec implementations, this uniqueness of keys from one key exchange to another is used to provide perfect forward secrecy. D-H is also used by the Internet Key Exchange (IKE) Protocol during session setup, where the identities of the communicating parties established and preferred encryption methods and shared secrets need to be agreed upon between the two entities.

D-H is used in SSL for authentication of the communicating parties and the negotiation of session keys and encryption methods.

When establishing a communication session, the SSH client and server compute a shared secret using the D-H algorithm. A hash of this shared secret is then generated and used as the session key to encrypt the communication channel.

Bad Key Exchanges

Because there isn't any authentication built into the Diffie-Hellman algorithm, implementations that use Diffie-Hellman-type key exchanges without some sort of authentication are vulnerable to man-in-the-middle (MITM) attacks. The most notable example of this type of behavior is the SSH-1 protocol. Since the protocol itself does not authenticate the client or the server, it's possible for someone to cleverly eavesdrop on the communications. This deficiency was one of the main reasons that the SSH-2 protocol was completely redeveloped from SSH-1. The SSH-2 protocol authenticates both the client and the server, and warns of or prevents any possible MITM attacks, depending on configuration, so long as the client and server have communicated at least once. However, even SSH-2 is vulnerable to MITM attacks prior to the first key exchange between the client and the server.

As an example of a MITM-type attack, consider that someone called Al is performing a standard Diffie-Hellman key exchange with Charlie for the very first time, while Beth is in a position such that all traffic between Al and Charlie passes through her network segment. Assuming Beth doesn't interfere with the key exchange, she will not be able to read any of the messages passed between Al and Charlie, because she will be unable to decrypt them. However, suppose that Beth intercepts the transmissions of Al and Charlie's public keys and she responds to them using her own public key. Al will think that Beth's public key is actually Charlie's public key and Charlie will think that Beth's public key is actually Al's public key.

When Al transmits a message to Charlie, he will encrypt it using Beth's public key. Beth will intercept the message and decrypt it using her private key. Once Beth has read the message, she encrypts it again using Charlie's public key and transmits the message on to Charlie. She may even modify the message contents if she so desires. Charlie then receives Beth's modified message, believing it to come from Al. He replies to Al and encrypts the message using Beth's public key. Beth again intercepts the message, decrypts it with her private key, and modifies it. Then she encrypts the new message with Al's public key and sends it on to Al, who receives it and believes it to be from Charlie.

Clearly, this type of communication is undesirable because a third party not only has access to confidential information, but she can also modify it at will. In this type of attack, no encryption is broken because Beth does not know either Al or Charlie's private keys, so the Diffie-Hellman algorithm isn't really at fault. Beware of the key exchange mechanism used by any public key encryption system. If the key exchange protocol does not authenticate at least one and preferably both sides of the connection, it may be vulnerable to MITM-type attacks. Authentication systems generally use some form of digital certificates (usually X.509), such as those available from Thawte or VeriSign.

II.C. Diffie–Hellman

Whitfield Diffie and Martin Hellman created the first public key algorithm in 1976. The Diffie–Hellman algorithm is used for key exchange and it is still in use today. The security of the algorithm comes from the complexity of computing discrete logarithms

If two people wish to communicate securely over an insecure line, they need to agree on a symmetric key with which to encrypt their communications. First a large prime number p and generator g must be produced. The value g must be primitive mod p, that is, it must be able to generate all elements in the field. Person A and B both require these values; they do not need to be secret so p and g may be sent in the clear. Person A then generates a random integer x and sends person B the result Ma=gx mod p. Person B generates a random integer y and sends person A the result Mb=gy mod p. Person B receives Ma and computes the symmetric key K=May mod p=gxy mod p and person A receives Mb and computes the same symmetric key K=Mbx mod p=gxy mod p. K can then be used as the key in a symmetric encryption algorithm to encrypt communications between person A and person B. The Diffie–Hellman algorithm is illustrated in Fig. 5.

With the Diffie–Hellman algorithm, a passive attacker (someone who can only read all communications between persons A and B) cannot determine the secret key K. The algorithm does not provide any authentication of either party so an active attacker who can intercept, inject, or modify messages could perform a man-in-the-middle attack and read all encrypted communications. In this case, the attacker would see p and g. When person A sends her Ma=gx mod p to person B, the attacker would intercept the message, calculate his own u value and send back Mc=gu mod p to person A. The attacker would also create his own v value and send Md=gv mod p to person B, then intercept the message Mb=gy mod p from person B. The attacker has now performed two Diffie–Hellman key agreements, one with person A and one with person B. The attacker and person A would calculate the shared symmetric key and start communicating in encrypted form. The same would happen with the attacker and person B. The attacker would decrypt the message from person A, read the information, re-encrypt it for person B, and send the new message to person B and vice versa. Neither person A nor B has any idea that the attacker is reading the communication. However, methods exist such as the station-to-station (STS) protocol to augment the Diffie–Hellman algorithm to provide authentication of the parties involved.

Example of Elliptic Curve Addition

Consider the EC defined in the previous example. (Also see sidebar: “Elliptic Curve Diffie–Hellman Algorithm”) [4].

Let P = (3, 10) and Q = (9, 7). Then P + Q = (x3, y3) is computed as follows:

λ=7−109−3=−36=−12=11∈Z23

x3 = 112 – 3 − 9 = 6 – 3 − 9 = −6 ≡ 17 (mod 23), and y3 = 11[3 − (–6)] − 10 = 11(9) − 10 = 89 ≡ 20 (mod 23). Hence P + Q = (17, 20).

Let P = (3, 10). Then 2P = P + P = (x3, y3) is computed as follows:

λ=3(32)+120=520=14=6∈Z23

x3 = 62 − 6 = 30 ≡ 7 (mod 23), and y3 = 6(3 – 7) − 10 = −24 − 10 = −11 ∈ 12 (mod 23).

Hence 2P = (7, 12).

Consider the following EC with Zp∗

y2modp=(x3+ax+b)modp

Set p = 11 and a = 1 and b = 2. Take a point P [4,2] and multiply it by 3; the resulting point will be on the curve with (4, 9).

Elliptic Curve Diffie–Hellman Algorithm

Alice has her EC and she chooses a secret random number d and computes a number on the curve QA = dA∗P [4]: Alice's public key: (p, a, b, QA). Alice's private key: dA.

Bob has his EC and he chooses a secret random number d and computes a number on the curve QB = dB∗P: Bob's public key: (p, a, b, QB). Bob's private key: dB.

Alice computes the shared secret key as

S=dA∗QB

Similarly, Bob computes the shared secret key as

S=dB∗QA

The shared secret key computed by Alice and Bob are the same for:

S=dB∗QA=dB∗dA∗P

Example of Elliptic Curve Addition

Consider the elliptic curve defined in the previous example. (Also see sidebar, “EC Diffie-Hellman Algorithm.”) [4].

Let P=(3, 10) and Q=(9, 7). Then P+Q=(x3, y3) is computed as follows:

λ=7−109−3=−36=−12=11∈Z23

x3=112−3−9=6−3−9=−6≡17 (mod 23), and y3=11(3−(–6)) −10=11(9) −10=89≡20(mod 23).

Hence P+Q=(17, 20).

Let P=(3,10). Then 2P=P+P=(x3, y3) is computed as follows:

λ=3(32)+120=520=14=6∈Z23

x3=62−6=30≡7 (mod 23), and y3=6 (3−7)−10=−24−10=−11∈12 (mod 23).

Hence 2P=(7, 12).

Consider the following elliptic curve with Zp*

y2modp=(x3+ax+b)modp

Set p=11 and a=1 and b=2. Take a point P (4, 2) and multiply it by 3; the resulting point will be on the curve with (4, 9).

EC Diffie-Hellman Algorithm

Alice has her elliptic curve, and she chooses a secret random number d and computes a number on the curve QA=dA*P[4].

Alice’s public key: (p, a, b, QA)

Alice’s private key: dA

Bob has his elliptic curve, and he chooses a secret random number d and computes a number on the curve QB=dB * P:

Bob’s public key: (p, a, b, QB)

Bob’s private key: dB

Alice computes the shared secret key as

S=dA*QB

Similarly, Bob computes the shared secret key as

S=dB*QA

The shared secret key computed by Alice and Bob are the same for:

S=dB*QA=dB*dA*P

Self-security

Self-security takes care of the security of configuration information, authentication/authorization, secure message exchange, and key life cycle management. Configuration information is a crucial element in all security mechanisms that are physically distributed. In an IDS based on agents, communication can be made through encrypted messages. For this purpose, all agents that constitute the system must register their public keys in a repository such as the XKMS Server1 [14]. The proposed model contains specific security measures for registering these keys in the XKMS Server. The security measure adopted employs a shared and temporary key called secret key that allows the encryption and decryption of messages used to register public keys between the agents and the XKMS Server. This secret key is unique, so it is different for each agent that performs this registry.

Figure 10.3 illustrates the process for registering a public key in the XKMS Server. The registry process begins when an agent and an XKMS Server agree and generate the same secret key, using the Diffie-Hellman algorithm [15]. Afterward, the agent starts its activities and separately generates its public and private key pair. A public key is encrypted using the secret key and the result is sent to the XKMS Server. Once the XKMS Server receives this encrypted message, it decrypts the message using the secret key, recovers the public key, and stores it in its PKI database. Then the XKMS Server sends an answer to the agent containing its public key in an encrypted message using the secret key. Once the agent receives this last message, it decrypts this message using the secret key and recovers the public key of the XKMS Server. When the public key exchange between an agent and the XKMS Server finishes, the server discards the secret key.

Another security measure proposed in this chapter is the use of cryptography for securing the configuration information of the XKMS Server. This information includes the parameters that are the static inputs for the MAC address of the server and the parameters of the Diffie-Hellman algorithm that are used to generate the secret key. This information is stored in a file because this avoids a man-in-the-middle attack [16] and prevents an intruder from interfering in the communication or successfully deluding the XKMS Server and any agent that is registering or locating a public key. The parameters contained in the file are encrypted, and the agents have static inputs for the MAC address of the XKMS Server. The configuration information stored in this file represents a barrier to possible attacks. The way this configuration file can be accessed is defined by the network administrator, for example, using Secure File Transfer Protocol (SFTP) or shared directories. In order to use this file, an agent must obtain the public key that is the pair of the private key used to encrypt the file. This public key is owned only by the XKMS Server. It is provided after the authentication and authorization process (presented in the next subsection). Note that this model consists of two parts: (1) the parameters of Diffie-Hellman are stored in an encrypted file, and (2) the public key needed to decrypt the file is obtained only after authentication and authorization of an agent in the XKMS Server.

In some IDSs, the configuration information is stored in a static document containing data that can seriously compromise the system in the event that it is captured, analyzed, and decrypted by intruders. The proposed solution is a protection model based on a dynamic generation of the configuration information and its storage in an encrypted file (XML document) that can be accessed in many ways, such as SFTP.

For this purpose, when the XKMS Server is started, the following procedures are performed: a public and private key pair is created specifically for this solution, called XKMS Server “configuration keys”; a file is generated at runtime; and its content is encrypted using the private key. The access to this file is done by agents, for example, through the SFTP protocol, and the reading is executed through the public key provided by the XKMS Server. This public key is distributed to agents that are authenticated and authorized by the XKMS Server.

Authentication/authorization and secure message exchange

The proposed solution is based on a robust mechanism of authentication and authorization of agents to ensure the security of the message exchange. The aim is to allow only the agents of the IDS to have access to the functionalities of the XKMS Server. As seen in Figure 10.3, the XKMS Server provides the elements for a secure communication channel. Before an agent can register its public key in the XKMS Server, the former must authenticate itself and obtain the authorization needed to access the latter. Figure 10.4 presents the steps for authentication and access control in the XKMS Server.

Figure 10.4. Schema of authentication and access control to key registration.

The process presented in Figure 10.4 has the following steps for authentication and authorization: An agent and the XKMS server exchange the certificates in order to activate the secure connection through SSL (Secure Socket Layer). Using the secure connection based on SSL, the agent sends its username and password to access the XKMS Server. The XKMS Server verifies the username and password and provides the public key needed to decrypt the configuration file that contains the parameters of the Diffie-Hellman algorithm. The agent uses this public key to decrypt the configuration file, obtaining the parameters to use the Diffie-Hellman algorithm. The agent and the XKMS Server use the Diffie-Hellman algorithm to exchange their public keys to secure the communication between agents.

Once an agent has obtained the public key of the XKMS Server and registered its public key, the messages are encrypted with the corresponding private key and decrypted by other agents using the public key of the sender. In our proposed framework, the messages are encrypted using XML-Encryption, XML-Signature, and Diffie-Hellman specifications, as presented in [15].

Key life cycle management

Cryptography is considered a critical element of any security system. Key management is directly related to the measures made to define a good design of a cryptographic system. These measures include the creation, exchange, storage, protection, utilization, verification, and renovation of keys. An IDS can profit from the XKMS Server for managing keys. The proposed solution is based on a model similar to PKI (Public Key Infrastructure), developed as an adaptation of XKMS. The role of the XKMS Server is to receive requests to find keys and return suitable answers. Figure 10.5 illustrates the XKMS Server functionality.

Figure 10.5. XKMS Server: key registration and lookup.

The XKMS Server designed for an IDS is based on a key management model that meets requirements of generation, lookup, exchange, storage, protection, utilization, and key verifications, but it does not have a mechanism that defines a key deadline and its consequent substitution done by agents [17]. The key renewal is an important security feature, because it protects the system by avoiding encrypted messages with corrupted public keys.

The proposed solution is based on a security model where all the keys stored in the XKMS Server will have a lifetime defined by the server through the use of digital statements called “timestamp.” Figure 10.6 shows how an entity (i.e., an agent) manages the lifetime of public keys. When an agent begins the process of generating a key pair, the system generates a timestamp that represents the creation date of the public key. This timestamp is then sent to the XKMS Server, which calculates the time that the public key is available for other agents in the system. This deadline defines the expiration time of a public key, which is then returned to the owner of the corresponding key. Once the deadline is over, a new generation and registration of a public key should proceed. The agent identifier, deadline, and public key are stored in the server’s PKI database.

Figure 10.6. XKMS Server functioning with a timestamp solution.

When an agent aims to establish a secure communication with another agent, it must acquire the public key from the XKMS Server. This key and deadline (i.e., expiration timestamp) are stored in the agent’s database. For each message sent, an agent (sender) verifies the validity of the other agent’s (receiver’s) key. If the key is available and the validity date is correct, then the communication proceeds. Otherwise, the agent requests the new public key to the XKMS server. There are cases where a key is verified by the sender with a correct validity date. The sender uses this key to encrypt a message that is read by a receiver later, when the validity date has already expired (i.e., the deadline is over), generating a failure in the validity date verification. Generally, this problem happens when there is a possible surcharge in the network and this causes a large time interval between the verification of the key validity by the sender and a reading of encrypted message with this key by the receiver. In the meantime, the receiver has changed its public key in the XKMS Server. Thus, the receiver refuses the message, launches a failure alert to the sender, and requests a new message encrypted with the current public key with a new validity date.

How PKI Works

Before we discuss how PKI works today, it is perhaps helpful to understand the term encryption and how PKI has evolved. The history of general cryptography almost certainly dates back to almost 2000 B.C. when Roman and Greek statesmen used simple alphabet-shifting algorithms to keep government communication private. Through time and civilizations, ciphering text played an important role in wars and politics. As modern times provided new communication methods, scrambling information became increasingly more important. World War II brought about the first use of the computer in the cracking of Germany's Enigma code. In 1952, President Truman created the National Security Agency at Fort Meade, Maryland. This agency, which is the center of U.S. cryptographic activity, fulfills two important national functions: It protects all military and executive communication from being intercepted, and it intercepts and unscrambles messages sent by other countries.

Although complexity increased, not much changed until the 1970s, when the National Security Agency (NSA) worked with Dr. Horst Feistel to establish the Data Encryption Standard (DES) and Whitfield Diffie and Martin Hellman introduced the first public key cryptography standard. Windows Server 2008 still uses Diffie-Hellman (DH) algorithms for SSL, Transport Layer Security (TLS), and IPSec. Another major force in modern cryptography came about in the late 1970s. RSA Labs, founded by Ronald Rivest, Adi Shamir, and Leonard Adleman, furthered the concept of key cryptography by developing a technology of key pairs, where plaintext that is encrypted by one key can be decrypted only by the other matching key.

There are three types of cryptographic functions. The hash function does not involve the use of a key at all, but it uses a mathematical algorithm on the data in order to scramble it. The secret key method of encryption, which involves the use of a single key, is used to encrypt and decrypt the information and is sometimes referred to as symmetric key cryptography. An excellent example of secret key encryption is the decoder ring you may have had as a child. Any person who obtained your decoder ring could read your “secret” information.

There are basically two types of symmetric algorithms. Block symmetric algorithms work by taking a given length of bits known as blocks. Stream symmetric algorithms operate on a single bit at a time. One well-known block algorithm is DES. Windows 2000 uses a modified DES and performs that operation on 64-bit blocks using every eighth bit for parity. The resulting ciphertext is the same length as the original cleartext. For export purposes the DES is also available with a 40-bit key.

One advantage of secret key encryption is the efficiency with which it takes a large amount of data and encrypts it quite rapidly. Symmetric algorithms can also be easily implemented at the hardware level. The major disadvantage of secret key encryption is that a single key is used for both encryption and decryption. There must be a secure way for the two parties to exchange the one secret key.

In the 1970s this disadvantage of secret key encryption was eliminated through the mathematical implementation of public key encryption. Public key encryption, also referred to as asymmetric cryptography, replaced the one shared key with each user's own pair of keys. One key is a public key, which is made available to everyone and is used for the encryption process only. The other key in the pair, the private key, is available only to the owner. The private key cannot be created as a result of the public key's being available. Any data that is encrypted by a public key can be decrypted only by using the private key of the pair. It is also possible for the owner to use a private key to encrypt sensitive information. If the data is encrypted by using the private key, then the public key in the pair of keys is needed to decrypt the data.

DH algorithms are known collectively as shared secret key cryptographies, also known as symmetric key encryption. Let's say we have two users, Greg and Matt, who want to communicate privately. With DH, Greg and Matt each generate a random number. Each of these numbers is known only to the person who generated it. Part one of the DH function changes each secret number into a nonsecret, or public, number. Greg and Matt now exchange the public numbers and then enter them into part two of the DH function. This results in a private key—one that is identical to both users. Using advanced mathematics, this shared secret key can be decrypted only by someone with access to one of the original random numbers. As long as Greg and Matt keep the original numbers hidden, the shared secret key cannot be reversed.

It should be apparent from the many and varied contributing sources to PKI technology that the need for management of this invaluable set of tools would become paramount. If PKI, like any other technology set, continued to develop without standards of any kind, then differing forms and evolutions of the technology would be implemented ad hoc throughout the world. Eventually, the theory holds that some iteration would render communication or operability between different forms impossible. At that point, the cost of standardization would be significant, and the amount of time lost in productivity and reconstruction of PKI systems would be immeasurable.

Thus, a set of standards was developed for PKI. The Public-Key Cryptography Standards (PKCS) are a set of standard protocols sued for securing the exchange of information through PKI. The list of these standards was actually established by RSA laboratories—the same organization that developed the original RSA encryption standard—along with a group of participating technology leaders that included Microsoft, Sun, and Apple.

Adding a New Security Certificate

1

Open Control Panel and under System and Maintenance | Administration Tools, double-click the Internet Information Services (IIS) Manager shortcut.

In the Internet Information Services (IIS) Manager management console click the server node, in the middle pane click Server Certificates.

In the right-hand Actions pane click Create Certificate Request.

In the Request Certificate dialog on the Distinguished Name Properties page (see Figure 5.18) provide the host name that will be used to access your site (e.g., www.contoso.com) along with your company information and click Next.

On the Cryptographic Service Provider Properties page choose a Cryptographic Server Provider, a minimum of 1,024 Bit Length for the key, and click Next (see Figure 5.19).

RSA SChannel Cryptographic Provider Uses an MD5 hash with an SHA hash, signed with an RSA private key. It supports SSL2, PCT1, SSL3, and TLS1 protocols.

DH SChannel Cryptographic Provider Uses the Diffie-Hellman algorithm and supports SSL3 and TLS1 protocols. Use this algorithm when you must exchange a secret key over an insecure network without prior communication with the client.

Bit Length The default length supported by most browsers and certificate authorities is 1,024 bits. With processors becoming more powerful, expect to see a move toward 2,048 bit length certificates past the year 2010. Be sure to check with your chosen certificate authority to ensure they will support bit lengths larger than 1,024 before increasing this value.

On the File Name page provide a path and name of a file where to sort the certificate request and click Next.

Contact your preferred certificate authority to obtain the response file for your request.

If you are looking to test out the SSL functionality there are a number of providers that will give you a free trial SSL certificate that lasts for anywhere from 15 to 60 days. This is handy because they have all the trust features of regular certificates with no cost.

When you obtain the response file, open IIS Manager and return to the Server Certificates section.

In the right-hand actions pane click Complete Certificate Request.

In the Complete Certificate Request dialog on the Specify Certificate Authority Response page, locate the Certificate Authority's Response file, provide a Friendly Name for the certificate, and click Next to complete the process.

Configuring & Implementing…

The Real Differences between SSL Certificates

When you are out shopping for an SSL certificate it can get quite confusing as to what the differences are between the various offerings. For the most part you are buying trust in that the certificate you will be issued is trusted by the client. Under the covers the technical differences boil down to these:

▪

Standard Certificate A basic security certificate that will suit most users and will work for 40-bit encryption up to 256-bit encryption in most modern browsers

▪

Server Gated Certificate Before the United States dropped its cryptography export laws in January of 2000 these certificates added a step in the security handshake to see whether the client could support stronger cryptographic algorithms (ciphers). This allowed older browsers an opportunity to step-up their level of encryption if they did not use 128-bit or higher encryption by default.

▪

Extended Validation Certificate From a technical perspective these certificates are no different than a standard certificate with the exception that they have some additional metadata attached to the certificate. This metadata is used by browsers that are capable of reading it to determine if they should identify for the user (e.g., turn the address bar green) that the site has gone through extra validation steps. The validation steps and data included are available in the extended validation certificate guidelines at www.cabforum.org. With the data in hand modern browsers will signal to the user through actions like turning the address bar green as shown in Figure 5.20. This feature of popular browsers like Internet Explorer 7 is meant to help users identify the site authenticity.

Figure 5.20. Internet Explorer Address Bar of a Site Using Extended Validation Certifi cate

▪

Wildcard Certificate One of the three preceding certificates, but using an asterisk (*) somewhere in the domain name to signify a wildcard value. This is generally considered a premium service and commercial providers reflect this fact in their pricing model.

When choosing certificates remember that the level of encryption used in most cases is decided on as a mutual agreement between the client and the server. Both parties can choose to use a minimum level of encryption. With IIS this value is represented by a single check box to force clients to use a minimum of 128-bit encryption or have IIS refuse the connection request. Other advertised features have no impact on the security provided by the SSL-enabled session.

With the certificate in place you can now bind the certificate to your Web site. Under the covers the security certificate is bound to an IP address since the request header information is encrypted when the server needs to determine which certificate to use. Once the certificate is bound you can choose to force the use of SSL on all or part of the site.

To enable secure communication on your Web site, follow these steps:

Open Control Panel and under System and Maintenance | Administration Tools, double-click the Internet Information Services (IIS) Manager shortcut.

In the Internet Information Services (IIS) Manager management console expand the server node, right-click your site, and select Edit Bindings.

In the Site Bindings dialog click Add.

In the Add Site Binding dialog set the Type to HTTPS. From the SSL Certificate list choose your certificate and click OK (see Figure 5.21).

In the Site Bindings dialog click Close.

Expand your site node, locate and click a folder (or select the site to enforce SSL on the site as a whole) that you wish to secure.

In the middle pane under Features View, double-click SSL Settings.

In the SSL Settings module check Require SSL, Require 128-bit SSL, and in the right-hand Actions pane click Apply (see Figure 5.22).

Most modern Web browsers support 128-bit SSL. This option was put in place because up until 2000 the United State government restricted the export of certain cryptographic algorithms, which left a good portion of the world stuck with 40- or 56-bit sessions, which provided a lesser degree of security.

Does Diffie

What is session key in Diffie

What type of encryption is Diffie

Is DH symmetric or asymmetric?