Securing Communications with Secure Socket Layer (SSL)

By default, all communication between the Web server and the client occurs over a clear-text connection, which has the potential to expose the information included in the requests and responses to an attacker able to listen to the communication at the network layer. This includes packet sniffing at a local network, or compromising a router or a proxy server that is located on the path between the client and the Web server. This can result in the unintended disclosure of the response information, which may contain sensitive information, client credentials that are sent as part of some authentication methods (such as basic authentication or forms-based authentication methods), cookies, and more. The attacker can sometimes successfully use this information to misrepresent the client by providing these credentials to the Web server in a replay attack.

To prevent this from happening, you can use the Secure Socket Layer (SSL) or the newer Transport Layer Security (TLS) protocols to secure the communication between the client and server. TLS is a widely accepted standard that most browser technologies implement. In the rest of this section, we will refer to both of these protocols collectively as SSL for ease of reference.

In addition to securing the communication between the client and the Web server, SSL serves to confirm the identity of the Web server to the client. This process is widely used on the Internet today to ensure that the client is dealing with the entity that the Web site claims to represent. IIS can also use it to establish the identity of the client, if the client has an acceptable certificate. Client certificates are discussed later in the section titled "Client Certificates" later in this chapter.

Configuring SSL

To configure SSL, you must perform the following steps:

1. Obtain a server certificate from a trusted Certificate Authority. The Certificate Authority (CA) must be a trusted root CA for all of the clients that connect to the Web site that uses this certificate. For intranet sites, this may be a domain CA provided by the Active Directory Certificate Services. For Internet sites, this is usually a CA that is trusted by most client browsers by default. You can obtain the certificate by making a certificate request using the Server Certificates feature in IIS Manager. Alternatively, you can use a self-issued (or self-signed) certificate if you control both the Web server and the clients, and if you intend to use this certificate for testing purposes.
2. Create a secure binding by using the HTTPS protocol and port 443 (or another port), and specify the server certificate for each Web site. You can do this by creating a binding in IIS Manager, or by adding a binding programmatically and then using the netsh http add sslcert ipport=IPAddress:443 certstorename=MY certhash=hash appid=GUID command to associate the certificate with the binding. You can obtain the certificate hash from the Certificates console by viewing the certificate details and copying the value of the Thumbprint property.

Note Unlike IIS 6.0, where certificate association information is stored in the metabase, and the Web Publishing Service (W3SVC) is responsible for associating the site bindings with certificates when it is started, IIS 7.0 stores the certificate information directly in the HTTP.sys configuration. You can manipulate these associations by using IIS Manager or by using the netsh http add sslcert command.

To be accepted by the clients, the server certificate must contain Common Name (CN) entries for all of the host headers that the Web site used. This needs to be done when the certificate is requested.

Note It is possible to have multiple SSL Web sites that use unique server certificates if each Web site uses a separate IP address or port for its HTTPS binding. As in IIS 6.0, IIS 7.0 does not support having multiple Web sites with their own server certificates if the HTTPS bindings for those Web sites are on the same IP address/port and differentiate only by using host headers. This is because the host header information is not available when the SSL negotiation occurs. Because of this, the only way to have multiple Web sites on the same IP address that use host headers is to configure all of those Web sites to use the same SSL certificate with a wildcard CN. For more information, see https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true.

For more information on configuring site bindings, see Chapter 9. You can also read more about requesting certificates in the IIS 7.0 online documentation at https://technet2.microsoft.com/windowsserver2008/en/library/d780d806-e8a8-4bc5-8d7a-9f045d1f3e221033.mspx?mfr=true.

Requiring SSL

To ensure that the communication between your Web server and clients is protected, you may choose to require that clients request your Web site content over secure connections. This is an effective way to protect clients' authentication credentials or sensitive cookies issued by the Web site over unsecure connections.

Caution If your Web site enables mixed SSL usage, such as by allowing the Web site to be accessed over both SSL and unsecure connections, or by allowing portions of your Web site to be accessed over unsecure connections, be aware that requests made over these connections may leak sensitive information. For example, if your Web site uses Forms authentication to authenticate users, uses cookie-based session state, or stores sensitive information about the user in cookies, your clients may leak these cookies when making requests over unsecure connections. Therefore, always prefer to protect your entire Web site with SSL by requiring SSL for the entire Web site's URL namespace. Also, configure your cookies to include the secure bit to make sure the browser will not attempt to send them over unencrypted connections.

You can require SSL in IIS Manager by selecting the Web server, Web site, or another node corresponding to the URL for which you'd like to require SSL. Then double-click SSL Settings. In this feature, select the Require SSL check box to mandate SSL, as shown in Figure 14-8. You also have the option of selecting the Require 128-Bit SSL check box.

Figure 14-8 Configuring SSL settings using IIS Manager.

Alternatively, you can require SSL by editing the system.webServer/security/access section directly by using Appcmd or another configuration API. For example, you can set this configuration using the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/access /sslFlags:enum

This command has the parameters presented in Table 14-17.

Table 14-17 Parameters for Configuring SSL Settings

Client Certificates

Though SSL is typically used to confirm the identity of the Web server to the client, it can also be used to confirm the client's identity to the Web server if the client has certificates issued by a CA that the Web server trusts. Client certificates can be used as part of a strong two-factor authentication scheme that requires both a user name/password as well as a physical authentication method to provide the client certificate, such as a Smart Card. Or, it can be used as a single authentication method with one of the client certificate mapping authentication methods that IIS supports.

To use client certificates, you must meet the following requirements:

• The Web site must be configured to use SSL and have a valid server certificate.
• The client must have a client certificate issued by a CA that the Web server trusts.

When a client makes a connection that uses SSL, the Web server negotiates the client certificates (if configured to do) by indicating the list of trusted CAs on the server, causing the client to respond with the list of certificates that are available on the client and that are issued by those CAs. The server then validates the certificates, including checking their expiration times and making sure that they are not listed on the Certificate Revocation List (CRL) on the Web server.

IIS supports multiple levels of using client certificates:

1. Negotiate certificates. This requests the client to provide a client certificate when the request is made, but it does not require the certificate. If the client provides it, the server validates the certificate, and the certificate is made available to the application. To do this, set the sslFlags attribute of the system.webServer/security/access configuration section to include SslNegotiateCert, as described in the section titled "Requiring SSL" earlier in this chapter.
2. Require certificates. This requires that the client provide a client certificate when the request is made. If the certificate is not provided, the request is rejected with a 403.7 – Client Certificate Required error. If the certificate is not successfully validated by the server, the request will be rejected with a 403.16 – Client Certificate Is Untrusted Or Invalid error. It could also be rejected with a 403.17 – Client Certificate Has Expired Or Is Not Yet Valid error. To require certificates, set the sslFlags attribute of the system.webServer/security/access configuration section to include SslNegotiateCert,Ssl-RequireCert, as described in the section titled "Requiring SSL" earlier in this chapter. You can require certificates to implement a strong two-factor authentication scheme. Alternatively, you can require certificates in conjunction with a client certificate mapping authentication scheme as the primary authentication scheme for your Web site. For more information, see the sections titled "Client Certificate Mapping Authentication" and "IIS Client Certificate Mapping Authentication" earlier in this chapter.
3. Authenticate users with client certificates. IIS can also be configured to authenticate clients based on the client certificates. To learn more about using client certificate authentication, see the sections titled "Client Certificate Mapping Authentication" and "IIS Client Certificate Mapping Authentication" earlier in this chapter.

< Back      Next >

© Microsoft. All Rights Reserved.