Understanding SSL | Microsoft IIS 6.0Administrator's Consultant

IIS supports SSL protocol version 3. SSL 3 enables encrypted data transfers between client browsers and Web servers. The sections that follow provide an overview on how SSL works and how it’s used.

Using SSL Encryption

As stated previously, encryption is the process of encoding information using a mathematical algorithm that makes it difficult for anyone other than the intended recipient to view the original information. The encryption algorithm uses a mathematical value, called a key, to scramble the data so that it can be recovered only by using the key.

Many techniques are available for encrypting information so that it can be exchanged. Some encryption techniques use a combination of public and private keys—one key can be shared and the other key can’t. Some encryption techniques use shared secret keys that are transferred between authenticated systems. SSL uses a technique called public key encryption, which combines private, public, and shared secret (session) keys.

In public key encryption there are three keys:

A public key available to any application that requests it
A private key known only to its owner
A session key created using public and private key data

IIS uses the public key encryption component in SSL to establish sessions between clients and servers. You should use SSL whenever you want to provide additional protection for data that’s transferred between clients and servers. Some specific instances in which you might want to use Certificate Services and SSL are the following:

When you remotely manage the Web server using the Administration Web site or operator administration pages
When your Web site has secure areas that contain sensitive company documents
When your Web site has pages that collect sensitive personal or financial information from visitors
When your Web site processes orders for goods or services and you collect credit or other personal information from customers

With SSL, users connect to Web pages using a secure Uniform Resource Locator (URL) that begins with https://. The https designator tells the browser to try to establish a secure connection with IIS. SSL connections for Web pages are made on port 443 by default, but you can change the port designator as necessary. As you set out to work with SSL, keep in mind that you can’t use host headers with SSL. With SSL, Hypertext Transfer Protocol (HTTP) requests are encrypted, and the host header name within the encrypted request can’t be used to determine the correct site to which a request must be routed.

After the client browser contacts the server using a secure URL, the server sends the browser its public key and server certificate. Next, the client and server negotiate the level of encryption to use for secure communications. The server always attempts to use the highest level of encryption it supports. Once the encryption level is established, the client browser creates a session key and uses the server’s public key to encrypt this information for transmission. Anyone intercepting the message at this point wouldn’t be able to read the session key— only the server’s private key can decrypt the message.

The IIS server decrypts the message sent by the client using its private key. The SSL session between the client and the server is now established. The session key can be used to encrypt and decrypt data transmitted between the client and server.

To recap, secure SSL sessions are established using the following technique:

The user’s Web browser contacts the server using a secure URL.
The IIS server sends the browser its public key and server certificate.
The client and server negotiate the level of encryption to use for the secure communications.
The client browser encrypts a session key with the server’s public key and sends the encrypted data back to the server.
The IIS Server decrypts the message sent by the client using its private key, and the session is established.
Both the client and the server use the session key to encrypt and decrypt transmitted data.

Using SSL Certificates

Not reflected in the previous discussion is the way in which SSL uses certificates. You can think of a certificate as an identity card that contains information needed to establish the identity of an application or user over a network. Certificates enable Web servers and users to authenticate one another before establishing a connection. Certificates also contain keys that need to establish SSL sessions between clients and servers.

In most cases certificates used by IIS, Web browsers, and Certificate Services conform to the X.509 standard. For this reason, they’re often referred to as X.509 certificates. Different versions of the X.509 standard have been issued (see RFC 3280 for more information on this standard). These versions have been extended from time to time as well. Two types of X.509 certificates are used:

Client certificates, which contain identifying information about a client
Server certificates, which contain identifying information about a server

Certificate authorities issue both types of certificates. A certificate authority (CA) is a trusted agency responsible for confirming the identity of users, organizations, and their servers and then issuing certificates that confirm these identities. Before issuing a client certificate, CAs require that you provide information that identifies you, your organization, and the client application you’re using. Before issuing a server certificate, CAs require that you provide information that identifies your organization and the server you’re using.

This chapter focuses on server certificates. When you’re choosing CAs to create your server certificates, you have several options. If you use Certificate Services, your organization can act as its own CA. When you act as your own CA, you enable SSL on your Web server using the following process:

Install Certificate Services on a server in the domain and then generate the root CA certificate.
Generate a certificate request file for each Web site on your server that has a unique name, and then use the certificate request files to create server certificates for your Web sites.
Install the certificates and then enable SSL on each applicable Web site.
Client browsers won’t recognize and trust your root CA certificate. To get browsers to trust the root CA, the user must install the certificate in the browser’s authorities store.
Initiate SSL connections by using URLs that begin with https://.

You can also use third-party CAs—and there’s an advantage to doing so. The third-party authority can vouch for your identity, and dozens of vendors are already configured as trusted CAs in Web browsers. In Microsoft Internet Explorer 5 or later, you can obtain a list of trusted authorities by completing the following steps:

From the Tools menu, select Internet Options. This displays the Internet Options dialog box.
Select the Content tab and then click Certificates. This displays the Certificates dialog box.
Select the Trusted Root Certification Authorities tab. You should now see a list of trusted root CAs.

When you use a trusted third-party authority, you enable SSL on your Web server using a different process from when you act as your own root CA. This process is as follows:

Generate a certificate request file for each Web site on your server that has a unique name.
Submit the certificate request files to a trusted third-party authority, such as Entrust, Equifax, Valicert, or Verisign. The CA will process the requests and send you certificates.
Install the certificates and then enable SSL on each applicable Web site.
Client browsers initiate SSL sessions using a secure URL beginning with https://.

Regardless of whether you act as your own CA or use a trusted CA, you must still manage the server certificates, and you use Certificate Services to do this. Server certificates can expire or be revoked, if necessary. For example, if your organization is an Internet service provider (ISP) that issues its own certificates, you might want your customers’ server certificates to expire annually. This forces customers to update their certificate information at least once a year to ensure that it’s current. You also might want to revoke a certificate when a customer cancels service.

Understanding SSL Encryption Strength

An SSL session’s encryption strength is directly proportional to the number of bits in the session key. This means that session keys with a greater number of bits are considerably more difficult to crack and, thus, are more secure.

The two most commonly used encryption levels for SSL sessions are 40-bit and 128-bit. Encryption at the 40-bit level is adequate for most needs, including e-commerce. Encryption at the 128-bit level provides added protection for sensitive personal and financial information. Most versions of Microsoft Windows Server 2003 shipped in the United States are configured with 128-bit encryption. Export versions of Windows Server 2003 have 40-bit encryption. To upgrade a server from 40-bit encryption to 128-bit encryption, you must install the 128-bit upgrade patch, which is available from Microsoft.

Don’t confuse the encryption level for SSL sessions (the strength of the session key expressed as bits) with the encryption level for SSL certificates (the strength of the certificate’s public and private keys expressed as bits). Most encryption keys (public and private) have a bit length of 512 or 1024. Domestic U.S. and export versions of most applications and operating systems support encryption keys with a bit length of 512. However, encryption keys with a bit length of 1024 or greater aren’t supported in the export versions of most applications and operating systems.

When a user attempts to establish an SSL session with your Web server, the user’s browser and the server use the bit length of their encryption keys to determine the strongest level of encryption possible. If the encryption keys use 512 bits, the level of encryption is set to 40 bits. If the encryption keys use 1024 bits, the level of encryption is set to 128 bits. Other key bit lengths and encryption levels are available.