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 by 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 the key must be used to recover the data.
Many techniques are available for encrypting information so that it can be exchanged. Some encryption techniques use a combination of public and private keys—the public key can be shared and the private 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 that's available to any application that requests it
• A private key that's known only to its owner
• A session key that's 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 follow:
• When you remotely manage the Web server by 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 by 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 by 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 uses its private key to decrypt the message sent by the client. 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:
1. The user's Web browser contacts the server by using a secure URL.
2. The IIS server sends the browser its public key and server certificate.
3. The client and server negotiate the level of encryption to use for the secure communications.
4. The client browser encrypts a session key with the server's public key and sends the encrypted data back to the server.
5. The IIS server uses its private key to decrypt the message sent by the client, and the session is established.
6. 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 needed 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), and these versions have been revised from time to time. 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.
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 use the following process to enable SSL on your Web server:
1. Install Active Directory Certificate Services on a server in the domain, and then generate the root CA certificate.
2. 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.
3. Install the certificates and then enable SSL on each applicable Web site.
4. 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.
5. Initiate SSL connections by using URLs that begin with https://.
Instead of using your own CAs, you can 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 version 5 or later, you can obtain a list of trusted authorities by completing the following steps:
1. On the Tools menu, select Internet Options. The Internet Options dialog box appears.
2. On the Content tab, click Certificates. The Certificates dialog box appears.
3. On 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 follow a different procedure on your Web server to enable SSL than when you act as your own root CA:
1. Create 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 Verisign. The 2. CA will process the requests and send you certificates.
3. Complete the certificate request by installing the certificate, and then enable SSL on each applicable Web site.
4. Client browsers initiate SSL sessions by using a secure URL beginning with https://.
Regardless of whether you act as your own CA or use a trusted CA, you still must manage the server certificates, and you use Active Directory 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 most commonly used encryption levels for SSL sessions are 40-bit, 128-bit, and 256-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 e-commerce. Encryption at the 256-bit level provides superior protection for sensitive personal and financial information. Most versions of Microsoft Windows Server shipped in the United States are configured with 256-bit encryption.
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 higher. 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. If the encryption keys use 2048 bits, the level of encryption is set to 256 bits. Other key bit lengths and encryption levels are available.
Source of Information : Microsoft Press Internet Information Services IIS 7.0 Administrators Pocket Consultant
Using SSL Encryption
As stated previously, encryption is the process of encoding information by 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 the key must be used to recover the data.
Many techniques are available for encrypting information so that it can be exchanged. Some encryption techniques use a combination of public and private keys—the public key can be shared and the private 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 that's available to any application that requests it
• A private key that's known only to its owner
• A session key that's 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 follow:
• When you remotely manage the Web server by 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 by 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 by 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 uses its private key to decrypt the message sent by the client. 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:
1. The user's Web browser contacts the server by using a secure URL.
2. The IIS server sends the browser its public key and server certificate.
3. The client and server negotiate the level of encryption to use for the secure communications.
4. The client browser encrypts a session key with the server's public key and sends the encrypted data back to the server.
5. The IIS server uses its private key to decrypt the message sent by the client, and the session is established.
6. 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 needed 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), and these versions have been revised from time to time. 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.
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 use the following process to enable SSL on your Web server:
1. Install Active Directory Certificate Services on a server in the domain, and then generate the root CA certificate.
2. 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.
3. Install the certificates and then enable SSL on each applicable Web site.
4. 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.
5. Initiate SSL connections by using URLs that begin with https://.
Instead of using your own CAs, you can 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 version 5 or later, you can obtain a list of trusted authorities by completing the following steps:
1. On the Tools menu, select Internet Options. The Internet Options dialog box appears.
2. On the Content tab, click Certificates. The Certificates dialog box appears.
3. On 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 follow a different procedure on your Web server to enable SSL than when you act as your own root CA:
1. Create 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 Verisign. The 2. CA will process the requests and send you certificates.
3. Complete the certificate request by installing the certificate, and then enable SSL on each applicable Web site.
4. Client browsers initiate SSL sessions by using a secure URL beginning with https://.
Regardless of whether you act as your own CA or use a trusted CA, you still must manage the server certificates, and you use Active Directory 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 most commonly used encryption levels for SSL sessions are 40-bit, 128-bit, and 256-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 e-commerce. Encryption at the 256-bit level provides superior protection for sensitive personal and financial information. Most versions of Microsoft Windows Server shipped in the United States are configured with 256-bit encryption.
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 higher. 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. If the encryption keys use 2048 bits, the level of encryption is set to 256 bits. Other key bit lengths and encryption levels are available.
Source of Information : Microsoft Press Internet Information Services IIS 7.0 Administrators Pocket Consultant
|
|
0 comments
Post a Comment